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THE  MODULAR  COMMAND  AND  CONTROL  EVALUATION  STRUCTURE  (MCES): 
APPLICATIONS  OF  AND  EXPANSION  TO  ARCHITECTURAL  EVALUATION 


PREFACE 

The  intent  of  consolidating  the  methodological  and  developmental 
gains  of  the  analytic  community  in  the  MCES  brought  this  effort 
to  the  Naval  Postgraduate  School  (NPS)  at  Monterey,  CA.  The 
Organization  of  the  Joint  Chiefs  of  Staff  (OJCS),  C3S,  were  the 
primary  sponsors  in  effecting  this  move.  The  move  allowed  the 
NPS  to  serve  as  the  base  of  operations  from  which  the  Principal 
Investigator,  Dr.  Ricki  Sweet,  could  synthesize  the  work  being 
done  and  could  start  the  validation  using  a  set  of  application 
studies . 

The  work  of  three  of  the  Joint  C3  Academic  Group  graduates  is 
incorporated  in  the  problem  areas  reported  herein.  Not  only 
during  the  period  of  their  stay  at  NPS,  but  also  repeatedly 
since,  Maj.  Pat  Gandee,  Capt.  Kevin  Briggs  and  Capt.  Ingabee 
Stone  (all  USAF)  have  provided  support  toward  the  continuation 
of  the  MCES  effort. 

In  addition,  the  MCES  was  briefed  to  NPS  students  and  faculty, 
at  various  stages  of  its  development. 
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Animated  discussions  of  its  implications  and  derivatives  into  a 
wide  variety  of  potential  applications  ensued.  Several  graduates 
specifically,  Lt.  Bruce  Nagy  (USN),  Lt.  Liese  Kennedy  (USN),  and 
Capt.  Frank  Prautzsch  (USA),  have  taken  these  insights  to  their 
next  duty  assignment  with  the  intention  and  opportunity  to 
continue  their  use. 

Further,  five  new  students  have  been  working  with  the  principal 
investigator  to  expand  the  earlier  work  and  to  add  new  problem 
areas  to  the  library  of  application  studies  being  created. 

Capt.  Gail  Kramer  (USAF)  and  Lt.  Colleen  Forster  (USN)  have  been 
working  in  the  area  of  the  Strategic  Defense  Initiative  (SDI), 
employing  the  MCES  to  further  define  relevant  measures  in  the 
BM/C3  area.  Capt,  Larry  Moss  (USA)  has  been  continuing 
Maj.  Gandee’s  work  on  the  IFFN  (Identification  Friend,  Foe,  or 
Neutral)  testbed.  Maj.  Nick  Hoffer  (USMC)  has  been  developing  an 
acquisition  application  in  the  JTIDs  area  for  the  Marine  Corps. 
Finally,  Lt.  Mary  Russo  (USN)  has  been  using  the  MCES  to  gain 
perspective  in  the  complex  world  of  C3  countermeasures  (C3CM). 

The  Joint  C3  Academic  Group  at  NPS  was  particularly  supportive  of 
this  effort.  However,  among  its  members,  Maj.  Tom  Brown  (USAF) 
made  extraordinary  contributions  to  the  students,  staff,  and 
especially  the  Principal  Investigator. 
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His  creative  graphics  clarified  the  representation  of  the  concepts 
with  which  the  MCES  dealt,  which  until  then  were  quite  nebulous. 
Further,  his  background  at  the  IFFN  testbed  was  particularly 
helpful  for  technical  orientation  in  that  aspect  of  the  research. 

Lois  Brunner,  senior  technical  staff  at  NPS ,  provided  substantive 
support  in  guidance  to  the  students,  theoretical  mathematics  and 
computer  support  of  C3,  and  the  considerable  logistics  of 
acquisition  and  subcontracting. 

NPS  offered  an  exceptional  forum  from  which  to  interact.  As  a 
result  of  this  contract,  together  with  the  travel  support 
available  under  this  contract,  the  MCES  was  briefed  to  high  level 
decision-makers  representing  Joint  Tactical  Command  Control  and 
Communications  Agency  (JTC3A),  Office  of  the  Secretary  of  Defense 
(OSD),  Office  of  the  Secretary  of  the  Navy  (OSN),  Space  and  Naval 
Warfare  Systems  Command  (SPAWAR),  Naval  Oceans  Systems  Center 
(NOSC) ,  Joint  Directors  of  Laboratories  (JDL),  OJCS,  Air  Force 
Operational  Test  and  Evaluation  Center  (AFOTEC),  JTF  IFFN  Testbed, 
AF/SDI,  AF/SA  and  a  wide  variety  of  other  government  agencies.  We 
understand  that  many  of  the  MCES  foci  will  be  used  by  these 
agencies  to  expedite  their  evaluations  of  C2  systems  and 
architectures . 


The  impact  of  these  application  studies  has  expanded  the  utility 
of  the  relatively  small  funding  base  extensively. 


M 
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All  of  these  interactions,  the  involvement  of  students,  and  indeed 
the  theoretical  perspective  underlying  much  of  the  MCES  were  made 
possible  through  the  professional  interest  of  Prof.  Michael  G. 
Sovereign,  Chairman  of  the  Joint  C3  Academic  Group  at  NPS.  His 
early  support  in  hosting  the  1985  Workshop  has  expanded  through 
the  years  as  he  has  been  in  the  forefront  of  enlarging  the  MCES 
usefulness  to  DOD. 

The  Department  of  Defense  (DOD)  contractor  environment  has  also 
supported  and  accepted  the  MCES  concepts.  MacDonald  Douglas  - 
Washington  Studies  and  Analysis  Group,  United  Technologies,  System 
Planning  Corporation,  Falcon  Associates,  and  Alphatech  were  among 
the  support  contractors  briefed.  In  the  ensuing  debate,  many  of 
the  original  concepts  were  expanded  to  incorporate  newly  shared 
insights . 

Finally,  two  other  academic  institutions  should  be  noted.  Both 
Massachusetts  Institute  of  Technology,  specifically  the 

Laboratory  for  Information  and  Decision  Sciences,  and  National 
Defense  University,  have  provided  free  exchange  and  interest  in 
the  work  set  forth  herein. 

It  is  important  that  a  word  be  said  here  about  cosponsors  and 
their  role  in  this  research. 
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First,  the  Naval  Air  Development  Center,  NADC,  has  sponsored  a 


separate  SDI-related  effort  described  above.  As  a  result  of  that 


effort,  there  has  been  extensive  interaction  with  Alphatech,  NADC 


and  SDI  as  well  as  with  the  MITRE  Corporation  and  AFSC/ESD/SDI . 


As  has  been  the  case  in  all  other  MCES  related  interactions,  the 


exchanges  provided  "theory”  expansion  and  elaboration. 


The  second  outside  sponsor  was  the  Naval  Surface  Weapons  Center, 


NSWC.  Not  only  financial  but  outstanding  technical  and  analytic 


support  was  provided  by  Dennis  Mensh.  His  use  of  the  MCES 


resulted  in  analytic  conclusions  which  contributed  greatly  to  MCES 


development.  Three  separate  studies,  one  for  the  Electro-Optics 


Association,  one  for  ONR/MIT  and  the  third  reported  both  to  NSWC 


and  in  this  report,  were  conducted  jointly  as  a  result  of  this 


effort.  In  addition,  SPAWAR,  OSN  and  NOSC  particularly  benefited 


from  briefings  of  this  work.  This  truly  synergistic  effort  has  by 


itself  expanded  the  productivity  of  this  effort  many  fold. 


As  usual  the  continuing  cadre  of  experts  from  the  community  has 


provided  yeoman  service  to  the  communication  of  these  results. 


Specifically,  the  review  of  the  last  draft  by  Prof.  Michael  G. 


Sovereign,  Dr.  Harold  Glazer  of  The  MITRE  Corporation  and  the 


COTR,  Dr.  John  Dockery  are  to  be  noted. 
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INTRODUCTION 

"There  is  a  lack  of  analytic  definition  as  to  what  a  C2 
architecture  is.  There  is  a  need  as  well  as  a  requirement  for 
generic  tools  to  evaluate  C2  systems  and  architectures.  Such 
tools  as  do  exist  are  usually  focused  upon  the  specific  aspects 
that  the  analyst  doing  the  problem  is  most  comfortable  with; 
regardless  of  their  fit  to  the  problem." 

It  was  from  such  a  perspective  that  the  sponsor  of  this  research 
formulated  this  broad  study  effort.  In  fact  the  perspective 
readily  translates  into  a  firm  requirement.  Build  a  tool  for 
the  systematic  comparison  of  C2/C3  architectures . 

The  Modular  Command  and  Control  Evaluation  Structure  (MCES) 
addresses  this  requirement.  Figure  1  displays  the  MCES 
structure.  This  report  provides  an  introduction  to  the  MCES  and 
traces  its  application  to  a  number  of  real  problems. 

The  MCES  may  be  viewed  as: 

(1)  A  structure  to  direct  the  evaluation  of  C2 
architectures ; 
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FIGURE  1 

MODULAR  COMMAND  AND  CONTROL  EVALUATION  STRUCTURE  (MCES) 
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(2)  A  paradigm  to  select  and  integrate  from  among  existing 
tools;  and,  finally, 

(3)  A  methodology  which  itself  may  be  used  for  evaluation, 
employing  a  common  structured  treatment. 

The  JCS  C3S  Initiative's  objective  was  to  provide  a  simple  yet 
powerful  paradigm  with  which  to  evaluate  alternative  C2 
architectures.  The  first  step  was  the  development  of  the  MCES 
Modules  to  be  used  by  staff  officers  tasked  with  evaluation  of 
C2/C3  systems/architectures.  For  example,  a  critical,  if  not  the 
critical  Module,  was  the  C2  Process.  The  information  processing 
model  adopted  was  then  to  be  built  into  the  MCES.  At  this  time, 
there  are  three  alternatives  for  this  component,  described 
below.  The  second  step  is  test  and  implementation.  This  report 
focuses  primarily  on  step  two. 

The  evolving  methodology  assumes  that  capabilities  of  selected  C2 
systems  can  be  greatly  improved  by  focussing  upon  both  system  and 
procedural  changes.  The  plan  was  to  assess  the  effectiveness  of 
a  specific  system  through  a  detailed  evaluation  of  its  C2/C3 
architecture.  This  single  detailed  study  was  intended  as  a 
demonstration  of  principal.  In  addition,  other  applications  of 
the  paradigm  were  to  be  scoped  for  subsequent  study. 
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These  evaluation  plans  were  intended  as  a  test  of  the  limits  to 
the  generalizability  of  the  MCES. 

For  the  purposes  of  this  initiative,  "architecture”  is  defined  as 
"an  integrated  set  of  systems  whose  physical  entities,  structure 
and  functionality  are  coherently  related".  Given  the  current 
state  of  semantic  ambiguity,  this  operational  definition  can 
tentatively  be  accepted  in  lieu  of  a  more  inclusive  and 
descriptive  one.  So  defined,  "architecture"  extends  a  commonly 
accepted,  JCS  Pub  #1  based  operational  definition  of  a  (C2) 
system.  Sharing  this  common  terminology  allows  direct 
application  of  the  established  MCES  methodology  to  actual  and 
proposed  architectural  problems.  (It  should  be  noted  that  ,  as 
with  effectiveness  measures,  the  term  "architecture"  may  be 
considered  to  apply  to  broad  principles  in  many  different  types 
of  applications.  Further,  based  upon  this  definition,  unless 
otherwise  specified,  the  term  "system"  can  also  be  read  as 
"system/architecture" . ) 
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THE  MCES  METHODOLOGY 

OVERVIEW 

The  MCES  consists  of  two  components: 

(1)  A  managerial  system.  This  is  a  guide  to  specifying  the 
problem  to  be  analyzed.  It  expedites  the  systematic 
specification  of  the  problem  by  focussing  on  identified 
essential  characteristics  of  C2  systems.  It  alleviates  the 
burden  on  decision  and  policy  making  resources  by  reducing 
the  time  and  personnel  needed  both  in  the  specification  and 
the  analysis  of  the  problem. 

(2)  An  analytic  system.  This  is  a  guide  to  the  analysis 
process  itself.  It  permits  a  senior  analyst  to  drive  a  C2 
evaluation  efficiently  to  a  concise  conclusion  and  provides 
the  supporting  data  for  decision-making.  The  MCES  supports 
the  analysis  process  through  a  set  of  standardized 
procedures  which  allow  the  resolution  of  commonly  occurring 
analytic  problems  via  pragmatic,  established  techniques. 
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THE  MODULES 


MODULE  1:  PROBLEM  FORMULATION 


This  Module  requires  a  description  of  the  decision-maker’s 
analysis  objectives  from  the  standpoint  of 


(1)  the  life  cycle  of  a  military  (C2)  system,  and 


(2)  the  level  of  analysis  prescribed. 


The  implementation  of  this  module  results  in  a  more 
precise  statement  of  the  problem  being  addressed.  Both 
the  appropriate  threat,  operational  and  deployment 
concepts,  and  other  environmental  factors,  the  scenarios  and 
the  assumptions  underlying  the  evaluation  are  made  explicit. 


MODULE  2:  C2  SYSTEM  BOUNDING 


The  problem  statement  output  by  Module  1  is  then  used  in  the 
second  Module  to  bound  the  C2  system  of  interest.  A  three 
dimensional  definition  of  a  C2  system  is  employed,  based  on 
JCS  Publications  1  and  2,  i.e.,  a  C2  system  consists  of 
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(1)  physical  entities,  (equipment,  software,  people  and 
their  associated  facilities), 

(2)  structure  (organization,  concepts  of  operation 
(including  procedures  and  protocols  and  information 
flow  patterns),  and 

(3)  (C2)  process  (the  functionality  or  "what  the 
system  is  doing"). 

This  definition  can  be  related  to  a  graphic 
representation,  of  the  levels  of  analysis,  which  the  MCES 
represents  as  an  "onion  skin",  see  Figure  2.  This  Module 
focuses  on  the  first  two  of  the  system  definition 
components:  physical  entities  and  structure. 

As  a  result  of  implementing  this  module,  the  system 
elements  of  the  problem  are  identified  and  categorized. 


MODULE  3:  C2  PROCESS  DEFINITION 


A  generic  C2  process  component  for  C3  systems  is  applied  as 
a  reference  in  the  third  Module.  It  forces  attention  on 
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ENVIRONMENT 

FORCE  BOUNDARY 

^C2  SYSTEM^ 
BOUNDARY 


WHERE: 

D  =  DIMENSION 
P  «  PERFORMANCE 
E  -  EFFECTIVENESS 
F  «  FORCE  OUTCOME 


FIGURE  2 

MODULE  2:  C2  SYSTEM  BOUNDING 
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(1)  the  environmental  "initiator”  of  the  C2  process, 
which  results  from  a  change  from  the  desired  state; 

(2)  the  internal  C2  process  functions  that 
characterize  what  the  system  is  doing,  (sense, 
assess,  generate,  select,  plan,  and  direct);  and 

(3)  the  input  to  and  output  from  the  internal  C2 
process . 

A  note  on  element  (2)  of  the  foregoing  is  in  order. 
Although  the  focus  of  the  1985  MCES  Workshop  Working  Group 
was  upon  the  C2  Conceptual  Process  Model,  subsequent  work 
with  this  model  explicitly  debated  this  orientation.  For 
example,  plan  may  be  seen  as  the  first  activity  in  the  C2 
Process.  Plan  may  also  be  referred  to  as  the 
"pre-real-time"  activity  of  command  and  control. 

As  a  result  of  the  implementation  of  this  module,  the 
functions  of  the  C2  process  for  a  given  problem  are 
identified  and  mapped  to  the  generic  simplified  C2  process 
loop,  as  shown  in  Figure  3. 
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MODULE  4:  INTEGRATION  OF  STATICS  AND  DYNAMICS 

The  fourth  Module  relates  the  C2  processes,  physical 
entities  and  structure.  Techniques  such  as  Data  Flow 
Diagrams  (DFDs)  or  Petri  Nets  may  be  used  to  show 
information  flow  through  the  C2  process  model.  (Figure  4 
shows  a  matrix  that  has  been  found  useful  in  integrating  the 
three  components  and  relating  them  to  a  hierarchical  view  of 
systems,  i.e.  ranging  from  elements  to  architectures.) 


As  an  example  of  a  technology  that  has  been  productive  in 
his  Module,  consider  the  DFDs  in  some  more  detail.  There, 
the  input/output  relationships  describe  the  internal 
information  flow  between  separate  process  functions,  as 
required  to  perform  the  mission  at  hand.  Then,  the 
hierarchical  relationships  between  the  individual  C2 
functions  are  determined.  Thus,  a  hierarchical  "structure" 
in  terms  of  the  information  flow  between  functions  within 
the  C2  process  is  defined.  This  produces  an  organizational 
structure,  which  could  reside  in  a  single  node  or  be 
distributed  between  command  nodes  or  between  command  and 
weapon  nodes.  Thereafter,  those  physical  entities  (man 
and/or  machine),  which  perform  functions  are  mapped  to  the 
output  from  the  functions. 
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STATICS 

DYNAMICS 

PHYSICAL  ENTITIES 

STRUCTURE 

PROCESS 

ELEMENTS 

SUBSYSTEM 

SYSTEM 

ARCHITECTURE 

FIGURE  4 

MODULE  4:  INTEGRATION  OF  STATICS  AND  DYNAMICS 
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The  C2  process  internal  processing  may  be  documented, 
specifying  how  the  information  is  input  and  output  from  the 
function . 


The  result  of  this  Module  is  a  synthesis  of  the  statics  and 
dynamics  defining  a  C2  system. 


MODULE  5:  SPECIFICATION  OF  MEASURES 


Based  upon  the  four  prior  modules,  the  fifth  module 
specifies  the  measures  necessary  to  address  the  problem  of 
interest.  The  definitional  categories  identified  above  may 
be  employed  to  derive  a  complete  set  of  relevant  measures, 
which  are  then  subjected  to  further  scrutiny.  First,  as 
shown  in  Figure  5,  these  are  compared  to  a  set  of  desired 
characteristics  for  measures,  which  reduces  the  number  to  a 
more  manageable  set. 


There  is  an  alternative  method  to  specifying  measures.  In 
this  case,  the  matrix  describing  the  C2  architecture  is 
completed  at  the  level  of  detail  appropriate  to  the  problem 
at  hand.  Accordingly,  one  to  "n"  entries  can  be  made  in 
each  cell  of  the  3  by  4  matrix,  shown  in  Figure  4.  The 
first  two  rows,  elements  and  subsystems,  represent  classes, 
whose  effected  members  would  be  selected. 
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CHARACTERISTICS 

DEFINITION 

Mission  Oriented 

Relates  to  force/system  mission. 

Discriminatory 

Identifies  real  differences  between 
alternatives . 

Measurable 

Can  be  computed  or  estimated. 

Quantitative 

Can  be  assigned  numbers  or  ranked. 

Realistic 

Relates  realistically  to  the  C2 
system  and  associated 
uncertainties . 

Objective 

Can  be  defined  or  derived, 
independent  of  subjective 
opinion.  (It  is  recognized 
that  some  measures  cannot  be 
objectively  defined.) 

Appropriate 

Relates  to  acceptable  standards  and 
analysis  objectives. 

Sensitive 

Reflects  changes  in  system 
variables . 

Inclusive 

Reflects  those  standards  required 
by  the  analysis  objectives. 

Independent 

Is  mutually  exclusive  with  respect 
to  other  measures. 

Simple 

Is  easily  understood  by  the  user. 

FIGURE  5 

DESIRED  CHARACTERISTICS  FOR  EVALUATION  MEASURES 
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One  or  more  measures,  suitable  to  both  the  problem  at  hand 
and  the  data  generator  available  are  identified.  (In  the 
event  that  both  conditions  cannot  be  satisfied,  the  nature 
of  the  problem  must  have  the  greater  influence.)  These 
measures  are  then  taken  as  the  critical  or  minimum  essential 
set  of  measures  for  the  problem  at  hand. 


The  appropriate  approach  may  be  selected  by  conducting  an 
experiment  with  a  small  excursion  within  the  same  problem 
domain.  Such  a  small  study  excursion  would  involve  a 
problem  for  which  the  set  of  exhaustive  measures  is 
relatively  small  and  easily  instrumented.  A  test  will 
determine  the  estimated  percent  of  variance  accounted  for  by 
the  "selected  set".  If  the  decisionmaker  finds  this 
variance  comfortable,  the  comparative  cost  of  the  selective 
vs.  exhaustive  technique  could  be  determined.  To  these  two 
factors,  a  third,  speed  of  producing  usable  results  should 
be  added. 

The  final  set  of  measures  selected  are  classified  as  to 


their  level  of  measurement,  i.e., 
(MOPs),  measures  of  effectiveness 
force  effectiveness  (MOFEs).  The 


measure!  of  performance 
(MOEs),  or  measures  of 
names  chosen  also  link  to 


the  kind  of  conclusion  that  can  be  drawn  in 
which  the  measures  are  applied. 


an  analysis  to 
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The  implementation  of  this  Module  results  in  the 
specification  of  a  set  of  measures  focussed  primarily  on  the 
C2  process  functions;  however,  it  also  often  includes  the 
static  components  of  the  C2  system. 

MODULE  6:  DATA  GENERATION 

The  generation  of  values  for  the  measures  of  Module  5  is 
addressed  by  this  Module.  Here,  one  of  several  types  of 
data  generators,  (i.e.,  exercises,  experiments,  simulations, 
or  subjective  judgements,  -  aka  relevant  experiences)  is 
selected.  The  measures  or  variables  for  measuring 
effectiveness  are  specified  in  the  prior  Module. 

Using  the  designated  data  generator,  the  values  to  be 
associated  with  these  measures  are  the  resultant  output  of 
the  implementation  of  this  Module.  These  values  may  be 
either  measured  directly,  or  be  derived  from  those  measured 
directly . 

MODULE  7:  AGGREGATION  OF  MEASURES 

The  final  Module  addresses  the  issue  of  how  to  aggregate  the 
observed  values  for  the  measures.  The  three  levels  of 
measurement,  together  with  sets  of  variables  through  which 
values  on  each  level  are  generated,  are  available. 
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Different  problem  areas,  addressing  different 
decision-makers  analytic  needs,  will  result  in  differing 
requirements  for  and  justification  of  the  algorithms  for  the 


aggregation  of 


the  constituent  measures. 


The  implementation  of  this  Module  provides  the  analysis 
results  tailored  to  address  the  problem  initially  posed  by 
the  decisionmaker  and  is  further  qualified  in  the  Problem 
Formulation  Module. 


SUMMARY  OF  THE  MCES 


At  least  two  courses  of  action  are  available  to  the 
decisionmaker,  based  on  results  provided.  On  the  one  hand,  he 
may  directly  implement  the  results  of  the  MCES-driven  analysis, 
if  they  are  framed  to  permit  such  action.  Alternatively,  he  may 
identify  the  need  for  further  study  and  change  the  problem 
statement,  requiring  iteration  of  the  MCES  analysis.  It  should 
be  noted  that  during  the  course  of  either  the  first  or 
subsequent  iterations,  the  decisionmaker  may  interact  with  the 
MCES  analysis  effort  by  identifying  errors  in  assumptions, 
clarifying  the  bounding,  etc.  Modifying  the  direction  taken  in 
the  analysis  would  be  accomplished  by  infusing  new  directions  or 
objectives  based  upon  the  results  of  the  Module  completed. 
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For  example,  bounding  the  C2  system  may  generate  the  observation 
that  significant  interfaces  are  outside  the  scope  of  the  study 
as  originally  conceived. 

TEST  OF  THE  MCES 

The  remainder  of  this  report  covers  the  detailed  application  of 
the  MCES.  Examples  were  taken  from  all  services  and  from  Joint 
operations.  One  example  in  particular  is  highlighted.  It 
concerns  an  analysis  of  a  Naval  Battle  Force  Architecture.  This 
is  called  "The  Designated  Architecture". 

Several  other  examples  were  considered  in  less  detail.  These 
are  called  "The  Selected  Architectures". 

The  choice  of  case  histories  was  partially  motivated  by 
historical  consideration,  as  related  to  community  participation 
in  the  forerunner  Workshops  on  the  general  question  of  C2/C3 
measures  of  effectiveness.  Before  beginning  a  detailed 
discussion  of  the  principal  case  histories,  some  historical 
background  is  in  order. 
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BACKGROUND 

THE  MEASURES  OF  EFFECTIVENESS  PHASE 

The  1984  a  Symposium  entitled  ’’Measures  of  Effectiveness  for  C3 
Evaluation  Symposium”  was  held  at  MITRE  Corporation,  Bedford, 
MA.  It  was  initially  triggered  by  a  challenge  from  General 
Eaglet  in  his  role  as  Deputy  Chief  of  Staff,  Plans  and  Programs 
Headquarters,  Air  Force  Systems  Command.  Specifically,  General 
Eaglet  invited  Air  Force  planners  to  determine  the  force 
effectiveness  of  C2  systems.  A  major  implication  was  that  the 
approach  taken  should  provide  a  methodology  that  will  allow 
"cradle  to  grave"  analysis  of  C2  systems.  This  requirement  is 
often  expressed  and  rarely  found  among  previously  employed 
assessment  structures. 

The  expert  knowledge  of  the  analytic  community  was  focussed  to 
respond  to  this  issue,  through  the  mechanism  of  the  Symposium 
and  its  Working  Groups.  Under  Symposium  Chairmen,  Dr.  Ricki 
Sweet  and  LTC  Thomas  Fagan  III,  five  working  groups  were  formed 


MCES  &  Architecture 


25 


The  Working  Group  Chairmen  were: 

Dr.  Zitta  Z.  Friedlander,  The  MITRE  Corporation; 

Griffin  F.  Hamilton,  EASTAN  Corporation; 

Linda  Hill,  SAI; 

Dennis  Holstein,  LOGICON;  and 
Richard  Hu,  Naval  Sea  Systems  Command. 

This  was  the  beginning  of  a  grass  roots  involvement  by  the 
analytic  community  in  the  subject  of  C2  Evaluation  to  which  this 
report  is  heir.  The  topics  addressed  by  the  working  groups 
included:  working  definitions,  conceptual  models,  the 

identification  of  MOEs,  evaluation  techniques  and  approaches, 
and  an  overall  appraisal  of  the  current  status  and  future  course 
of  MOE  analysis. 

Deliberations  of  the  1984  Symposium  were  reported  to  an  audience 
of  close  to  100  attendees  at  the  52nd  MORS  C-3  (Measures  of 
Effectiveness)  Working  Group.  Presentations  were  made  by  the 
Working  Group  Chairmen  as  well  as  by  LTC  Edward  C.  Jonson, 
Director  of  Long  Range  Planning,  ESD/XR;  Ted  Jarvis,  The  MITRE 
Corporation;  and  Dr.  Morton  L.  Metersky,  NADC. 
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Based  on  the  expressed  interest  and  need  for  further  attention 
to  the  problem  of  evaluating  C2  systems  in  terms  of  their 
contribution  to  force  effectiveness,  MORS  sponsored  an  interim 
Workshop,  based  upon  a  proposal  developed  by  Dr,  Sweet,  Dr. 
Michael  G.  Sovereign,  Chairman,  Joint  C3  Academic  Group,  Naval 
Postgraduate  School,  and  Dr.  Metersky. 

A  C2  Measures  of  Effectiveness  "Strawman"  provided  the 
participants  with  a  framework  for  their  subsequent 
deliberations.  The  Strawman  was  developed  by  the  Workshop 
organizers,  together  with  the  1985  working  group  chairmen,  each 
of  whom  had  a  specific  subject  matter  responsibility. 

Dr.  William  Foster,  The  MITRE  Corporation,  headed  the 
"Applications"  working  group.  Mr.  Walker  Land,  The  IBM 
Corporation,  chaired  the  "Conceptual  Model"  working  group. 

Mr.  Richard  "Hap"  Miller,  OSD,  guided  the  "MOE  Specification" 
working  group.  Dr.  Stuart  Brodsky,  The  Sperry  Corporation, 
spearheaded  the  "Mathematics  Formulation"  working  group. 


At  the  end  of  the  1985  C2  MOE  Workshop,  the  Strawman  had  been 
critically  reviewed  and  revised.  Thereafter,  the  process  of 
preparing  an  integrated  presentation  of  this  work  proceeded. 
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A  report  was  presented  at  a  Special  Session  of  the  53rd  MORS. 
This  report  was  in  the  form  of  seven  presentations,  one  from 
each  of  the  organizers  and  one  from  each  of  the  working  group 
chairmen.  (Mr.  Charles  Smith  of  Nichols  Research  Corporation 
replaced  Mr.  Miller  and  Dr.  Conrad  Strack  of  Systems  Planning 
Corporation  replaced  Dr.  Brodsky  for  these  presentations.) 

The  final  draft  of  the  Workshop  deliberations  was  presented  to 
the  attendees,  the  MORS  Board  of  Directors  and  participants  from 
the  Workshop.  Comments  received  from  these  "reviewers"  were 
integrated  into  the  document.  This  document  was  published  as  a 
MORS  sponsored  document  in  June  1986. 

THE  MCES  PHASE  Is  EMERGENCE 

In  the  meantime,  the  organizers  developed  a  follow-on  proposal 
to  further  apply  the  structure  which  evolved  from  the  prior 
meetings.  Under  MORS  sponsorship,  jointly  with  the  Naval 
Postgraduate  School,  six  working  group  chairmen  were  recruited 
to  expand  and  apply  the  MCES  methodology  to  specifically 
evaluate  the  effectiveness  (or  force  effectiveness)  of  C2 
systems . 

Six  service  community  input  application  candidates  were 
suggested.  Each  was  proposed  by  a  sponsor  and  was  represented  at 
the  Workshop  by  the  "Problem  Advocate". 
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The  Army  Tactical  architectural  candidate  problem,  brought 
by  Maj.  B.  Galing  and  Maj.  R.  Wimberly  of  the  TRADOC 
Research  Element  in  Monterey,  posed  the  question  "How  can 
the  SHORAD/FAAD  Platoon  command  and  control  be  improved  to 
increase  the  number  of  engagements  of  threat  aircraft? 

The  Air  Force  Tactical  architectural  candidate  problem, 
brought  by  Maj.  P.  Gandee  on  behalf  of  Col.  D.  Archino, 
test  director  of  the  Identification  Friend,  Foe,  Neutral 
(IFFN)  testbed  (Kirtland  AFB),  centered  upon  the 
utilization  of  the  IFFN  testbed  to  evaluate  the  flow  of  C2 
information  throughout  the  C2  structure  specific  to  air 
defense.  The  question  addressed  was  "is  this  structure 
useful  in  evaluating  information  collected  to  determine  who 
was  winning  the  war?" 

The  Air  Force  Strategic  architectural  candidate  problem, 
brought  jointly  by  Maj.  Bruce  Thieman  of  0JCS-C3S  and 
Dr.  Tom  Rona  of  OSD/DASD  was  to  perform  a  mission  analysis 
to  define  a  concept  definition  for  a  strategic  command  and 
control  (SCC)  system  in  the  circa  2000-2020  time  frame. 

The  Navy  Tactical  architectural  candidate  problem,  brought 
by  Prof.  Dennis  Mensh,  on  behalf  of  the  NSWC,  was  to  develop 
architectures  for  battle  force  information  systems. 
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The  architectures  were  to  relate  measures  of  effectiveness 
of  command  and  control  of  a  Navy  Anti-Air  Warfare  (AAW) 
System,  the  C2  Process  model  and  Navy  functional  flow 
diagrams  and  description  (F2D2)  Process  (presently  used  by 
COMSPAWAR) 

The  Joint  Tactical  architectural  candidate  problem, 
brought  by  Lt.  Bruce  Nagy,  NOSC,  centered  upon  the 
definition  of  measures  to  evaluate  TADIL  J  communications 
protocol.  This  turned  out  to  be  two  problems:  (1)  the 
comparison  of  implementation  with  protocol  specifications, 
and  (2)  given  implementation,  the  determination  of  how  well 
the  TADIL  J  system  supports  required  information  exchanges 
among  joint  tactical  data  systems  (TDS). 

The  Joint  Strategic  architectural  candidate  problem, 
brought  by  Dr.  M.  Leonardo  on  behalf  of  SDIO,  centered  upon 
the  development  of  a  concept  of  operations  for  C2  of  ICBM 
launch  detection  (LD)  sensors. 

During  the  1986  Workshop  on  the  Evaluation  of  C2  Systems,  these 
application  studies  were  scoped,  i.e.,  a  plan  to  carry  out  an 
appropriate  analysis,  guided  by  the  MCES,  was  developed.  All 
participants,  especially  the  problem  advocates,  endorsed  the 
methodology  and  the  scoping  of  the  problem  which  resulted  from 


those  deliberations 
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The  results  of  this  Workshop  were  presented  at  a  Special  Session 
of  MORS  in  June,  1986  by  the  chairmen  of  the  Working  Groups. 


This  effort  represented  the  voluntary  contributions  by 
government,  military,  and  civilian  agencies,  and  by  companies 
associated  with  DOD,  as  well  as  the  personal  contribution  of 
time  and  energy  of  over  one  hundred  experts.  Coordination  of 
such  an  effort  has  been  the  single  most  challenging  aspect  of 
this  endeavor;  all  the  individuals  involved  are  overloaded  by 
their  own  work  plans,  and  respond  to  the  deadlines  and 
constraints  of  this  work  in  the  spare  time  that  only  very  busy 
people  seem  to  find. 


THE  MCES  PHASE  II:  TEST 


The  detailed  working  out  of  a  number  of  the  1986  Workshop 
candidates  forms  the  basis  of  this  phase.  Community  involvement 
remained  high  at  the  selected  host  agencies.  To  that  was  added 
the  work  of  student  teams  from  the  Naval  Postgraduate  School. 

For  the  first  time  in  its  evolution,  this  work  was  under  the 
full-time  management  and  direction  of  a  Principal  Investigator. 
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SUMMARY 

The  MCES  development  started  with  widespread  community 
discussion  leading  to  the  mandate  to  develop  a  generic  approach 
to  the  evaluation  of  C2  systems.  The  objectives  of  this 
approach  were  to  develop  and,  to  the  extent  possible,  to 
quantify  measures  of  effectiveness  appropriate  to  the  C2  systems 
of  interest. 

Further,  wherever  relevant,  it  should  be  attempted  to  relate  the 
C2  system  to  some  measure(s)  of  its  contribution  to  force 
effectiveness.  Finally,  all  phases  of  the  life  cycle  of  the 
military  system  should  be  amenable  to  analysis  using  this 
approach.  Indeed,  a  single  system  should  be  able  to  be 
continuously  evaluated  during  its  tenure. 

The  MCES  evolved  as  any  scientific  development:  (1)  public 
discussion  and  mandate  for  clarification;  (2)  setting  up  the 
nature  of  the  problem,  the  tools,  definitions,  and  potential 
directions;  (3)  first  order  development  of  the  identified 
components;  (4)  specification  of  the  interrelationships  of  the 
components;  (5)  testing  of  the  theory  with  real  problems,  i.e., 
extra-laboratory  experiments;  and  (6)  refining  the  structure  in 


accordance  with  the  test  results 
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Throughout  this  process,  tools  and  models  which  provide  depth  in 
one  or  more  of  the  Modules,  are  identified,  developed,  and/or 
integrated  into  the  MCES.  Today,  having  gone  through  the  first 
cycle  of  this  scientific  development,  the  many  participants  in 
this  journey  look  forward  to  the  continuing  iteration  of  the 
last  two  steps.  This  process,  we  are  confident,  will  lead  to  a 
further  refined,  bounded  and  specified  generic  methodology  that 
will  fulfill  many  of  the  requirements  implied  by  the  initial 
direction . 
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THE  0JCS-C3S  SPONSORED  WORK: 

A  C3  ARCHITECTURE  STUDY  USING  MCES  METHODOLOGY  i 

i 

f 

I 

I 

OVERVIEW 

! 

I 

As  indicated  earlier,  the  0JCS-C3S  initiative^  objective  was  to 
provide  a  simple  yet  powerful  paradigm  with  which  to  evaluate 

I 

alternative  C2  architectures.  The  first  step  was  the 
development  of  the  MCES.  The  second  step  is  test  and 
implementation.  This  chapter  focuses  on  step  two. 

The  architectural  studies  scoped  as  part  of  the  1986  Workshop 
were  the  candidates  for  the  work  undertaken  in  the  0JCS-C3S 
initiative . 

(1)  The  Navy  Battle  Force  Architectural  study,  a  follow-on 
to  the  Workshop  Navy  Tactical  Working  Group  deliberations, 
is  the  specific  detailed  study  which  is  considered  a 
demonstration  of  principle. 


(2)  The  IFFN  problem  represents  the  Air  Force  Tactical 
Problem  from  the  Workshop  and  is  a  rather  detailed  scoping, 
which  is  being  carried  forward  by  the  Workshop  sponsors. 
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(3)  The  Air  Force  Strategic  problem,  called  the  SuperCINC 
problem  after  the  Workshop,  was  carried  through  the  first 
two  modules  of  the  MCES  in  some  detail, 

(4)  In  addition,  a  new  study  related  to  the  set  of 
OSD-identified  critical  C3I  problems  from  which  the 
SuperCINC  problem  was  taken,  has  been  added.  This  is 
identified  as  the  SAC  operational  testing  problem  and 
relates  to  the  integration  of  new  equipment  into  an  existin 
architecture . 

These  four  problems  will  be  presented  in  varying  detail  in 

subsequent  sections  of  this  chapter. 

(5)  The  SDI  problem  was  undertaken  as  the  Joint  Strategic 
problem.  The  architectural  issues  were  to  examine  the 
assignment  of  functions  to  people/platforms.  However,  the 
designated  analytic  need  was  found  to  be  immature  in  its 
formulation  to  continue  under  this  study.  Indeed,  we  have 
learned  that  the  MCES  must  often  be  employed  more  than  once 
to  scope  a  problem  in  concept  development.  Further,  this 
experience  has  pointed  out  that  in  an  arena  where  there  are 
a  large  number  of  deferentially  tasked  actors,  the  MCES 
cannot  be  effectively  used  to  impose  order. 


MCES  &  Architecture 


35 


Instead,  a  second  scoping,  under  separate  funding,  is  being 
undertaken  for  a  subset  of  SDI-related  measurement  problems, 
where  the  participants  recognize  the  need  for  a  synthesized 
approach  to  the  problem. 

(6)  and  (7)  Finally,  two  of  the  Workshop  problems  were  not 
further  developed  under  this  study.  The  Army  SHORAD  problem 
was  set  aside  pending  resources  to  continue  further.  The 
Joint  Tactical  Problem  was  to  be  separately  continued  under 
the  aegis  of  the  sponsors  of  the  problem,  NOSC. 
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THE  DESIGNATED  ARCHITECTURE: 

NAVY  BATTLE  FORCE  ARCHITECTURAL  STUDY 

This  study  was  undertaken  with  the  primary  support  of  the  Naval 
Surface  Weapons  Center  (NSWC).  Dr.  Ricki  Sweet  was  Principal 
Investigator.  Prof.  Dennis  Mensh  was  the  senior  analyst  and 
technical  and  scientific  advisor  in  behalf  of  NSWC  for  this 
research.  NSWC  will  use  this  research  to  provide  appropriate 
measures  reflecting  the  command  and  control  process  into  data 
generation  tools,  such  as  the  Ship  Combat  Simulation  System 
(SCSS).  This  study  is  unclassif led . 

In  this  study,  a  complete  iteration  of  the  MCES  is  conducted. 

The  results  of  each  Module  are  summarized.  A  separate  study 
contains  another  detailed  application  of  the  MCES.  The  latter 
should  be  regarded  as  a  detailed  case  history  for  architectural 
design  environments.  It  should  be  considered  as  a  source 
document  for  someone  wishing  to  experiment  with  the  MCES  at  this 
time.  Together  with  the  work  of  Maj.  Pat  Gandee,  the  two 
comprise  the  most  detailed  evaluations  using  the  MCES.  These 
documents  are  presented  in  the  Appendix  to  this  report. 
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MODULE  Is  PROBLEM  FORMULATION 

The  Initial  Problem  Statement: 

The  objective  of  this  research  was  to  demonstrate  the 
utility  of  the  MCES  in  the  evaluation  of  competing  C2 
architectures  by  focussing  upor  both  system  and  procedural 
changes.  The  subject  of  this  research  is  Navy  Battle  Force 
Architectural  analyses. 

Assumptions : 

Architectural  analyses  require  first  the  determination  of 
what  the  system  is  to  do;  next,  how  it  is  to  do  it;  and 
finally,  how  we  will  know  it  is  done.  Functionality  is  seen 
as  the  given.  Alternatives  are  seen  as  different 
architectures  and/or  different  operating  modes.  The 
measures  defined  are  the  parameters  within  which  evaluation 
of  competing  architectures  is  accomplished. 

Accordingly,  the  MCES  may  be  designated  as  the  structured 
guide  through  the  inherent  analysis  process.  The  route 
will  be  illustrated  through  the  data  generated  by  a  Navy 
Battle  Force  exercise, 
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The  Level  Of  Decision: 

What  life  cycle  phase  is  the  program  in? 

In  general,  the  SCSS  is  used  in  the  design  phases  of 
combat  systems.  The  NSWC-sponsored  research  was  a 
feasibility  study  which  focussed  upon  inputting 
operational  environment  data  to  this  design  tool.  New 
databases  to  be  imbedded  in  the  SCSS  can  be  based  upon 
the  data  from  a  real  world  exercise  so  that  these 
databases  will  explicitly  reflect  previously  implicit 
command  and  control  operations. 

At  what  management  level  is  the  decision  maker? 


The  decision  maker  in  this  case  is  at  the  division 
level.  It  is  expected  that  NSWC  will  staff  the  results 
of  the  study  and  make  recommendations  to  SPAWAR  Working 
Group  III  under  Capt.  Hay.  This  effort  will  be 
focussed  upon  the  improvement  of  modeling  and 
simulation  efforts  in  behalf  of  evaluation  of  competing 


C2  systems  by  inserting  exercise  data  as 
validation/verification  of  the  databases  used  by  the 
existing  models  and  simulations. 
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Critical  Elements  To  Describe  The  System  Of  Interest 

The  following  question  was  formulated  for  the  problem 
addressed  by  this  study: 

What  is  the  concept  of  operations  for  the  exercise  in 
which  the  Navy  Battle  Force  Architecture  is  expected 
to  operate? 

The  exercise’s  operational  concept  is  classified. 

It  is  provided  in  Readiex  86-1  Script/Operational 
concept.  For  the  purposes  of  this  analysis,  the 
composite  warfare  coordinator  (CWC)  concept  is 
employed,  thus  a  delegated  pattern  of  authority  is  the 
focal  point  of  the  training  and  demonstration  of  the 
exercise . 

MODULES  2  AND  3:  C2  SYSTEM  BOUNDING  AND  C2  PROCESS  DEFINITION 

MCES  provides  definitional  guidance  for  the  bounding  and  process 
definition  Modules.  A  matrix  whose  columns  represent  the 
components  of  a  system,  i.e.,  physical  entities,  structure,  and 
process,  (ref.  1). 
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Process  refers  to  functionality  or  what  the  system  is  doing, 
i.e.,  plan,  sense,  assess,  generate,  select,  and  direct.  In 
this  problem,  plan  is  taken  as  a  pre-real  time  activity,  and  is 
considered  the  first  command  and  control  process  function. 

The  rows  of  this  definitional  matrix  are  denoted  by  a 
hierarchical  view  of  systems,  i.e.,  elements,  subsystems,  system 
and  architecture.  The  ’’element"  is  the  lowest  level: 
"architecture"  is  the  top  level. 

Figure  6  provides  an  example  of  the  results  of  the  System 
Bounding  and  Process  Definition.  This  leads  to  development  of 
measures  for  quantifying  the  dimensionality  of  the  system,  the 
performance  of  the  system,  and  the  effectiveness  of  a  combat 
system  in  terms  of  the  overall  system  performance. 

MODULE  4:  INTEGRATION  OF  STATICS  AND  DYNAMICS 


Ms 
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Statics  and  dynamics  address  the  various  architectures  that  are 
being  analyzed.  Statics  is  equivalent  tc  the  physical  entities 
and  the  structure.  Since  the  structure  changes  very  slowly  over 


HP 


time,  it  can  be  taken  as  quasi-static;  whereas  "dynamics"  is 
equivalent  to  the  process,  which  changes  rapidly.  At  the 
element  level,  the  "sensor"  performs  the  sense  function. 
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FIGURE  6 

NAVY  BATTLE  FORCE  EXAMPLE  OF  SYSTEM  BOUNDING 
AND  PROCESS  DEFINITION 
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At  the  subsystem  (relative  to  the  battle-force)  level,  the 
combat  system,  composed  of  physical  entities,  as  defined  above 
is  employed  by  an  organizational  unit,  a  Warfare  Area,  e.g., 
Alpha  Whiskey,  and  performs  the  functions  "plan",  "assess", 
"generate",  "select",  and  "direct". 

For  the  purposes  of  this  analysis,  the  integration  is 
accomplished  by  making  explicit  the  relationships  among  these 
components . 


As  shown  at  the  element  level  in  the  Figure  6  example,  the 
sensor,  a  piece  of  equipment,  is  assigned  to  the  Sensor  Operator 
Next,  at  the  system  level,  Tactical  Flag  Command  Center  (TFCC)  , 
also  composed  of  the  same  physical  entities  as  at  the  subsytem 
level,  performs  similar  functions  at  a  higher  level.  Finally, 
at  the  architecture  level,  the  battle  force,  similarly  composed, 
is  organizationally  responsible  as  the  battle  force  information 
management  system,  which  performs  its  functions  at  the  highest 
level . 

There  is  a  similar  relationship  between  the  entries  of  the 
columns.  For  physical  entities,  the  sensor  provides  information 
from  the  environment  upon  which  a  target  assessment  is  made  by 
the  combat  system.  The  combat  system  transmits  the  assessment 
to  the  TFCC,  which  is  used  by  .the  battle  force. 
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The  organizational  structure  is  directly  hierarchical.  Finally, 
the  process  can  be  seen  as  distributed  between  the  levels 
indicated.  The  relationship  between  the  column  entries  is  also 
important  in  relation  to  aggregation  of  measures. 

After  these  relationships  are  made  explicit,  the  MCES  provides 
the  guidance  for  a  set  of  both  quantitative  and  qualitative 
measures  based  upon  any  selected  form  of  data  generation.  These 
are  geared  to  the  application  objectives  of  the  decisionmaker. 
All  data  generation  techniques  should  output  values  for  a 
standard  set  of  measures  to  be  used  to  evaluate  competing 
architectural  alternatives.  Specification  of  measures,  data 
generation,  aggregation  of  measures  and  the  presentation  of  data 
to  the  decisionmaker  are  subsequently  discussed. 

MODULE  5:  SPECIFICATION  OF  MEASURES 

The  MCES  provides  a  framework  for  specification  of  measures. 

Four  types  of  measures  are  given.  Two  are  measured  inside  the 
boundary  of  the  C2  system,  i.e.,  dimensional  parameters  and 
MOPs.  Two  are  measured  outside  the  boundary  of  the  C2  system, 


i.e.,  MOEs  and  MOFEs 
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The  boundary  is  taken  to  be  the  delineation  between  the  system 
being  studied  and  its  environment,  e.g.,  if  the  physical 
entities  of  the  system  of  interest  are  located  in  the  command 
post  (TFCC),  its  external  elements  include  aircraft,  ships  and 
their  associated  combat  systems;  its  internal  elements  include 
subsystems  such  as  sensors,  computers,  and  internal 
communication.  (It  may  be  necessary  to  reflect  such 
environmental  entities  as  scenarios  and  threats  for  some 
specific  measures.)  It  should  be  clear  that  the  boundary  varies 
with  the  analysis  being  undertaken.  However,  for  any  set  of 
alternatives  being  evaluated  the  boundary  is  fixed  across 
systems . 

"Dimensional  parameters"  are  defined  as  the  properties  or 
characteristics  inherent  in  the  physical  entities  whose 
values  determine  system  behavior  and  the  structure  under 
question,  even  when  at  rest  (size,  weight,  aperture  size, 
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capacity,  number  of  pixels,  luminosity). 
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"MOPs"  are  also  closely  related  to  inherent  parameters 
(physical  and  structural)  but  measure  attributes  of  system 
behavior  such  as  "gain",  "throughput",  "error  rate",  "false 
alarm  rate",  and  "signal-to-noise  ratio".  In  short,  MOPs 
reflect  the  "what"  of  the  system.  Figure  7  presents  an 
example  of  the  matrix  of  MOPs  that  correspond  to  the  statics 
and  dynamics  of  Figure  6. 
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FIGURE  7 

NAVY  BATTLE  FORCE  EXAMPLE  OF  MOP  MATRIX 
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"MOEs"  measures  how  well  the  C2  system  performs  its 
functions  in  an  operational  environment.  Implicit  or 
explicit  reference  to  a  standard  against  which 
"effectiveness"  can  be  ascertained  is  required.  The 
standard  may  reflect  predicted  perfect  performance,  e.g., 
probability  of  detection  implies  the  potential  of  all 
objects  in  the  environment  being  detected.  Some  examples 
are  "probability  of  detection",  "reaction  time",  "number  of 
targets  nominated  for  engagement",  and  "susceptibility  of 
deception" . 

"MOFEs"  are  a  measure  of  how  a  C2  system  and  the  force 
(sensors,  C2  system,  and  weapons)  of  which  it  is  a  part 
performs  missions.  An  example  might  be  "surviving  and 
connected  warheads".  At  this  time,  MOFEs  derived  from  the 
exercise  data  are  not  available. 

MODULE  6:  DATA  GENERATION 

A  number  of  methods  may  be  used  to  generate  data  for  MOPs,  MOEs 
and  MOFEs.  Existing  simulation  programs  and  models  are  both 
general  and  detailed. 

This  report  uses  the  guidance  provided  above  to  extract  some  of 
the  appropriate  data  required  by  Figures  6  &  7  from  an  at-sea 
exercise.  The  tasks  involved  in  this  effort  include: 
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1.  Identification  of  appropriate  measures: 

Based  upon  the  guidance  provided  by  the  MCES,  the  following 
MOPs  were  identified  as  appropriate  to  the  evaluation  of  the 
mission  performance  evidenced  in  an  exercise:  tempo; 
organization;  (C2  Process)  function;  time;  tempo  by 
organization;  tempo  by  (C2  Process)  function;  structure 
by  ( C 2  Process)  function;  function  by  organization  by  time; 
and  bias  measures,  e.g.,  missing  functions. 

2.  Definition  of  selected  measures: 

a.  Tempo .  Tempo  represents  the  frequency  and  number 

of  activities  over  the  duration  of  the  exercise. 
Operationally,  this  measure  depends  upon  the  accuracy 
of  the  log  keeper.  Each  entry  in  the  log  is  entered  on 
a  time  line  identified  by  day  and  indexed  in  accordance 
with  military  time.  The  pattern  of  these  "hash  marks" 
is  taken  to  represent  the  tempo  of  operations  during 
the  exercise.  Since  a  time  line  is  essential  to 
designate  tempo,  this  measure  is  inclusive  of  the  time 
measure.  Figure  8  shows  the  tempo  of  operations  during 
an  approximately  six  hour  slice  of  day  1  of  the 
exercise . 
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b.  Organization .  Four  organizations  are  represented 
in  the  exercise  studied  herein.  These  may  be 
described  in  terms  of  the  mission  area  they  represent 
within  the  overall  CWC  (Composite  Warfare  Coordinator) 
structure.  The  four  organizations  are  ASW 
(Anti-Submarine  Warfare),  ASUW  (Anti-Surface  Warfare), 
AAW  (Anti-Air  Warfare)  and  EW  (Electronic  Warfare). 
Activities  relating  to  each  organization  are  reported 
for  that  organization  separately.  The  logs  indicate  data 
from  the  perspective  of  the  OTC  and  the  ASUWC.  The 
organization  is  both  the  subject  and  the  ob  ject  of  the 
log  entries  shown .  Two  or  more  organizational  entities 
may  be  represented  by  the  same  entry.  Figure  9 
indicates  organizational  structure  in  terms  of 
direction  of  information  flow,  i.e.,  messages  received 
by  or  initiated  by  the  OTC. 

c.  (C2  Process)  functions.  These  functions  are 
defined  in  ref.  (1)  Section  5. 4. 1.1.  Operationally, 
the  logs  do  not  always  allow  a  one-to-one  mapping  of 
entries  to  functions.  Therefore,  if  log  entries  were 
not  explicit,  operational  experience  was  used  to  map 
the  entries  to  the  functions.  Often,  the  nature  of  the 
logs  prevented  single  function  determination. 
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35 
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FIGURE  9 

NAVY  BATTI.K  FORCE  MOPS:  ORGANIZATIONAL  STRUCTURE 
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In  those  cases,  the  largest  set  of  functions  that 
would  accommodate  all  the  implied  functions  was  used 
for  such  occurrences.  It  is  clear  that  for  the 
exercise  log,  there  is  no  single-thread  extractable 
independent  set  of  measures. 

Each  of  these  subsets  may  be  seen  separately  but 
since  some  are  not  independent,  the  explanation  and 
assigned  value  for  the  set  is  complex.  At  one  extreme. 


those  sets  may  be  seen  as  arbitrarily  grouped,  due  to 
the  interpretation  of  the  log.  Alternatively, 
a  "set"  may  represent  a  unique  internal  feedback 
relationship.  Of  course,  there  are  many  other 
potential  explanations.  The  implications  for 
measurement  vary,  based  upon  the  explanation  adopted. 
Figure  10  shows  the  C2  Process  functions  and  their 
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frequencies  during  the  same  period  of  time  during  the 


K. 


exercise . 


d.  Time .  Time,  as  opposed  to  tempo,  relates  only  to 
the  elapsed  time  (by  day).  Time  can  be  segmented  by 
looking  at  the  elapsed  time  between  events  or  a  single 
time  designation  (representing  the  elapsed  time  from  an 
arbitrary  origin,  i.e.,  midnight)  may  be  used. 
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Since  time"  meets  all  the  measurement  criteria  for  a 
ratio  scale,  it  is  particularly  convenient  to  use  a  time 
scale  upon  which  to  relate  all  other  measures.  Time  is 
shown  in  Figure  8. 


e.  Interactions. 


(1)  Two-way  interactions  reflect  the  relationships 
between  the  columns  in  Figure  6.  These  include: 


(a)  Organizational  stress.  Here  the  tempo  of 
activities,  subject  to  the  limitations  of 
reporting,  indicated  above,  are  reported 
separately  for  each  warfare  area.  Tempo  for 
all  exercise  activities  and  for  activities 
at  the  OTC  is  also  shown  in  Figure  8. 


(b)  Functional  information  flow.  Subject  to 
the  limitation  of  independence  discussed 
above,  functions  are  designated  by  the 
information  flow  patterns.  Figure  11  indicates 


the  extent  and  direction  of  such  occurrences. 
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(c)  Functional  stress.  Each  function  set  mav 
be  designated  on  a  separate  time  line  and  a 
separate  hash  mark  indicated  at  each  time 
where  the  set  may  be  inferred  to  have 
occurred,  based  upon  log  entries.  Figures  8  and 
12  show  this  relationship  for  the  OTC. 


(2)  Functional  Interoperability  -  The  three-way 
interaction  of  variables,  function  by  organization 
by  time,  may  be  shown  by  linking  the  same 
functional  sub-set  across  time  lines.  This  linkage 
may  be  inferred  from  Figure  12.  Such  a  process 
assumes  there  is  a  natural  causal  and  temporal 
relationship  or  sequence  in  the  occurrence  of  the  set 
from  one  organization  to  another,  e.g.,  the  AGSP 
sub-set  occurs  at  the  ASUW  organization  at  0715 
thereafter  at  AAW  at  0820.  These  two  occurrences  are 
assumed  to  be  causally  and  temporally  linked  and  are 
therefore  graphically  joined.  Alternatively,  a 
sequence,  or  scale,  from  one  sub-set  to  another  may 
be  assumed,  e.g.,  (1)  sense  (S),  (2)  sense/assess 

(SA)...(10)  Direct  (D).  Figure  10  shows  the 
points  on  the  scale  which  would  evolve. 
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If  one  accepts  the  sequence  and  causality 
assumptions,  points  could  be  linked  according  to 
assigned  ordinal  scale  values  across  time  lines  for 
each  organization. 

This  interaction  may  also  be  taken  as  the  formal 
definition  of  "functional  interoperability". 

(a)  Bias  measures 

In  addition  to  the  sources  of  bias  indicated 
above,  four  specific  indications  of  bias  in 
the  underlying  data,  i.e.,  the  logs,  must  be 
noted . 

1.  Missing  functions.  If  we  assume  an 
essential  sequence  to  the  functions, 
even  defined  as  broadly  as  indicated 
above,  there  is  evidence  of  functions 
missing  from  the  logs  from  which  to 
infer  the  appropriate  functional 
sub-set . 
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2.  Errors  in  functions.  These  mis-IDed, 
are  considered  as  valid  data  for  the  C2 
process  functions.  Within  the  exercise, 
as  reported  in  the  log,  there  were 
functions  which  were  incorrectly 
performed . 

3.  Missing  data.  There  are  long 
periods  of  no  data  from  the  logs,  the 
activity  during  which  we  have  no  way  of 
inferring;  and 

4.  Observer  unreliability.  There  are 
clearly  differences  in  recording  style 
and  content  between  different  keepers  of 
the  exercise  logs. 

In  the  attempt  to  provide  appropriate  measures  to  address 
evaluation  issues,  all  of  the  measures  discussed,  except  those 
relevant  to  time,  are  MOPs.  Time-based  measures  and  those  which 
are  compared  with  the  exercise  script  (representing  ground 
truth)  are  MOEs.  In  the  sense  intended  here,  "ground  truth"  is 
taken  as  the  set  of  standards  which  system  parameters  must  meet 
in  order  to  determine  the  level  of  effectiveness  to  be 


determined 
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Ultimately,  a  few  measures  can  be  developed  from  the  exercise 
data  for  MOFEs.  Since  one  mission  objective  of  the  scenario 
script  for  the  exercise  was  to  get  through  the  choke  point,  an 
MOFE  could  be  derived  which  reflects  the  extent  of  this  mission 
accomplishment.  As  an  example  of  such  a  MOFE,  the  number  of 
ships  that  went  through  the  choke  point  could  be  compared  with 
the  number  of  ships  which  were  supposed  to  go  through  the  choke 
point . 

MODULE  7:  AGGREGATION  OF  MEASURES 

A  number  of  measures  describe  each  entry  in  columns  of  Figure 
6.  However,  the  meaningfulness  of  this  process  may  be 
questioned  when  applied  across  entries,  even  though  it  is 
mathematically  possible  to  aggregate  measures.  Some  of  these, 
of  course,  will  be  directly  aggregable,  e.g.,  time  for  the 
sensor  to  detect  a  contact  may  be  added  to  the  time  for  the 
combat  system  to  assess  the  contact  as  hostile,  friendly  or 
neutral,  which  may  be  added  to  other  time  intervals  to  get  an 
overall  reaction  time.  Some  will  be  indirectly  aggregated  since 
they  are  essential  to  the  calculation  of  the  measures  propelled 
forward,  e.g,,  sensor  probability  of  detection  is  a  function  of 
the  false  alarm  rate,  rate  not  meaningful  as  an  independent 
measure  at  the  combat  system  level. 
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Finally,  there  are  qualitative  measures  necessary  for  evaluation 
at  each  level,  but  not  able  to  be  manipulated  within  our  usual 
analytic  techniques.  This  latter  group  falls  within  "research 
to  be  done"  and  "techniques  about  which  the  community  is  yet  to 
be  educated  (or  convinced)"  from  the  standpoint  of  adoption. 

FEEDBACK  TO  THE  DECISION-MAKER 


The  results  derived  in  this  study  were  briefed  to  the  sponsor, 
NSWC,  on  22  July  1986.  Findings  developed  in  this  Battle  Force 
Architectural  Study  and  in  the  overall  0JCS-C3S  study  were 
briefed  at  several  separate  meeting  of  the  Warfare  Systems 
Architecture  Working  Group  II  meetings  from  June  through  August 
1986.  This  cross  fertilization  has  been  particularly  helpful  to 
this  study  in  that  it  forced  clarification  of  both  the  concepts 
and  their  communication. 

SUMMARY 


The  findings  of  this  application  were  accepted  by  NSWC 
management  and  will  be  input  to  future  work  on  this  C2 
architecture . 


This  research  led  to  the  following  lessons  learned  in  regard  to 
the  MCES  as  a  tool  for  evaluating  the  effectiveness  of  command 
and  control  systems: 


MCES  &  Architecture 


61 


(1)  MCES  can  be  used  to  determine  the  necessary  data  to  be 
collected,  estimated,  or  simulated  for  a  data  base  so  that 
the  entries  can  be  used  to  answer  the  C2  design  problems  at 
hand . 


(2)  MCES  can  be  effectively  applied  to  a  combat  system  with 
strong  C2  elements. 

(3)  MCES  can  be  used  to  structure  the  collection  of  data  in 
exercises . 

(4)  MCES  was  used  to  provide  an  operational  definition  of 
functional  interoperability  for  the  case  at  hand. 


(5)  This  application  lead  to  a  series  of  in  sights  and 
expansions  of  the  MCES: 

a) .  The  recognition  that  the  relationships  between  the 
functions  of  the  C2  process  model  are  not  linear,  but 
are  recursive,  complex  and  undefinable  at  this  time. 

b) .  The  plan  function  of  the  C2  process  model  may  be 
considered  in  real  or  pre-real  time.  In  the  former 
case,  it  follows  the  Workshop  generic  model.  In  the 
latter  case,  it  may  be  removed  from  the  sequence  or 
placed  first  in  that  sequence. 
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c)  The  matrix  approach  as  an  alternative  to  the  onion 
skin  forces  an  aggregational  definition  of 
architectures.  Namely,  elements  aggregate  to 
sub-systems  to  systems  and  finally  to  architectures. 

d)  The  matrix  approach  to  C2  analysis  requires  all 
three  definitional  components,  in  whole  or  in 
illustrative  parts,  to  provide  holistic  data  upon  which 
to  base  evaluative  conclusions  re  alternative 
architectures . 

(6)  MCES  leads  to  the  direct  specification  of  a  minimum 
essential  set  of  measures  for  evaluation  of  C2  systems. 

(7)  MCES  provided  the  concept  for  measures  based  upon  real 
world  inputs  to  study  both  interoperability  and  the  inherent 
operational  (and  therefore  acquisition)  problems  of  both 
architectures  and  requirements. 
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THE  SELECTED  ARCHITECTURES: 

IFFN  TESTBED  ARCHITECTURAL  STUDY 


OVERVIEW 

This  study  was  undertaken  with  primary  support  of  the  Naval 
Postgraduate  School  and  OJCS.  Maj.  Pat  Gandee  was  the 
Investigator.  As  the  thesis  advisor,  Dr.  Ricki  Sweet  provided 
methodological  guidance.  Maj.  Mike  Gray  and  Col.  Dave  Archino 
provided  technical  and  scientific  advise  on  behalf  of  the  IFFN 
testbed.  The  IFFN  testbed  will  use  this  research  to  provide 
focus  in  test  series  number  2,  currently  in  the  detailed 
planning  stage.  The  results  reported  here  are  unclassified. 

The  IFFN  problem  represents  the  Air  Force  Tactical  Problem  from 
the  1985  Workshop.  It  is  a  rather  detailed  scoping  of  the 
problem  and  served  as  Maj  Gandee's  thesis  primarily  to  support 
needs  identified  by  the  sponsors  of  the  problem. 

MODULE  1:  PROBLEM  FORMULATION 


The  goal  of  this  study  was  to  apply  the  MCES  as  an  evaluation 
tool  to  examine  the  air  defense  C2  problem.  The  IFFN  testbed 
addresses  the  air  defense  identification  problem,  a  subset  of 
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The  Initial  Problem  Statement : 

The  initial  problem  statement  as  developed  during  the  1985 
Workshop,  was: 

How  effective  is  the  air  defense  C2  system  in  the 
central  region  of  Europe  in  providing  decision-makers 
the  means  to  assess  and  employ  air  defense  assets  to 
meet  overall  mission  objectives?  Different  operational 
concerns  were  also  to  be  considered,  e.g.,  procedural 
control,  so  that  questions  such  as  "Under  what 
conditions  is  centralized  or  decentralized  control  more 
effective?"  could  be  answered. 


Assumptions : 


1.  The  mission  and  its  environment  (friends,  foe, 
neutral,  weather)  are  specified. 


2.  The  friendly  weapon  systems  are  limited  to  SAMs  and 
fighters  with  beyond  visual  range  (BVR)  munitions. 
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Scenario : 


A  conventional  threat  scenario  was  chosen  where  stress  of 


the  C2  system  could  be  affected  by  varying  traffic  volume, 
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ECM  jamming  of  radars,  communications  jamming  and  varying 

weather  conditions. 

Level  Of  Decision : 

What  life  cycle  phase  is  the  program  in? 

The  operational  test  community  is  expected  to  use  the 
results  of  this  study  to  structure  test  designs  to 
answer  operational  issues.  The  test  concept  uses  men  in 
the  loop  at  command  centers  and  in  the  weapon  systems 
employing  real  world  operational  procedures  against 
varied  threat  scenarios.  The  testbed  is  representative 
of  the  European  air  defense  C2  system,  and  must  operate 
in  an  environment  of  friendly,  enemy  and  neutral 
aircraft  to  perform  the  air  defense  mission. 

At  what  management  level  is  the  decisionmaker? 

The  IFFN  testbed  focuses  its  analysis  on  specific 
concerns  of  Army,  Air  Force,  NATO  and  DOD 
decision-makers  regarding  the  role  of  identification  as 
it  contributes  to  the  effectiveness  of  the  C2  process. 
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Critical  Elements  To  Describe  The  System  Of  Interest : 

Emphasizing  the  battle  management  functions  necessary  to 
control  air  defense  forces  in  central  Europe,  the  C2  system 
may  be  defined  by: 

1.  Geographic  areas  of  responsibility  -  for  the  IFFN 
testbed  within  the  NATO  4ATAF  sector,  and 

2.  Physical  elements  needed  to  perform  or  support  the 
C2  process  -  command  centers  and  information  sources. 

The  following  question  was  formulated  for  the  problem  of 
the  IFFN  testbed: 

How  will  the  programmed  C2  system  and  weapon  systems 
operate  together? 

MODULE  2:  C2  SYSTEM  BOUNDING 


The  first  component,  physical  entities,  of  the  air  defense 
system  may  be  indicated  by  the  command  centers  that  perform  the 
battle  management  functions.  These  are: 


MCES  &  Architectures 


67 


1.  Sector  Operations  Center  (SOC) 

2.  Control  and  Reporting  Center  (CRC) 

3.  Control  and  Reporting  Post  (CRP) 

4.  Brigade  Fire  Detection  Center  (BDG) 

5.  Battalion  Fire  Detection  Center  (BN  ) 

Identification  sources  considered  to  be  within  the  C2  system 
are : 


1.  NATO  Airborne  Early  Warning  System  (NAEW) 

2.  Special  information  system  (Intelligence)  (SIS) 

3.  Other  information  Sources,  e.g.,  flight  plans. 


Since  weapon  systems  also  perform  command  and  control  functions 
under  certain  operational  concepts,  the  C2  system  included  the 
weapons  systems  when  they  performed  C2  functions.  The  air 
defense  weapon  systems,  are  the  F-15  Eagle  (all  weather  fighter) 
and  the  HAWK  and  PATRIOT  SAMs. 

The  second  component  of  the  C2  system  bounding  Module  is 
structure.  For  this  system,  structure  may  be  designated  by 
information  flow.  The  functional  input/output  describes  the 
information  flow  between  separate  organizational  entities  and 


their  respective  C2  processes,  which  are  required  to  perform  the 


mission  at  hand. 
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In  this  information  flow,  the  commander  and  the  subordinates 


perform  separate  C2  processes.  These  processes  are  related. 


The  commander's  decision  begins  with  information  about  a  change 


in  state  in  the  environment  (input)  and  ends  with  directions  to 


his  subordinates.  These  directions  require  the  subordinates  to 


perform  some  set  of  actions  the  commander  has  determined  will 


remedy  this  change  in  state  (output). 


These  orders  are  received  by  the  subordinates  as  input  to  their 


process.  The  outputs  from  the  subordinates'  process  are 


detailed  instructions.  These,  in  turn,  are  input  to  the  force. 


thereby  coupling  this  latter  organizational  entity  to  the  prior 


two  levels.  Data  flow  diagrams  (DFD),  see  Figure  13,  describe 


the  input/output  relationships  that  exist  between  C2  functions 


(circle  on  the  diagram).  With  this  flow  of  information,  a 


transform  analysis  may  be  shaped. 


The  first  information  set  shown  in  this  figure  refers  to  target 


information.  First,  targets  are  DETECTED,  then  IDENTIFIED,  and 


finally  they  are  ASSESSED  in  relation  to  mission  goals.  The 


information  flows  from  DETECT  to  IDENTIFY  to  ASSESS  THREAT. 


The  second  information  set  assigns  enemy  targets  to  SAMs  or 


fighters  and  matches  individual  weapon  systems  to  the  targets. 
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1  RADAR  CONTACT 

2  CONTACT /POSITION /DIRECT  ION 

3  FRIEND/FOE/NEUTRAL 

4  PRIORITIZE  FOE  TARGETS 

5  ASSIGN  TARGET  TO  FIGHTERS 

6  ASSIGN  TARGET  TO  SAMS 

7  ALLOCATE  TARGET  TO  FIGHTER  AND  CONTROLLER 

0  PROVIDE  DIRECTION  AND  INFORMATION  TO  FIGHTER 

9  ALLOCATE  TARGET  TO  SAM  FIRE  UNIT 

10  MONITOR  ENGAGEMENTS 


FIGURE  13 


IFFN  TESTBED  STUDY:  SINGLE  C2  NODE  DFD 
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ASSESS  THREAT  is  the  function  where  the  main  perception  is 
formed.  Information  flows  in  to  formulate  perceptions. 
Information  flows  out  as  decisions  based  upon  these  perceptions. 

Therefore,  this  function  may  be  seen  as  the  superordinate 
function.  As  such,  it  is  called  the  C2  process  center.  A 
graphic  of  this  transform  analysis  is  shown  in  Figure  14. 

MODULE  3:  C2  PROCESS  DEFINITION 

IFFN  JTF  was  dealing  with  a  distributed  C2  system.  Therefore, 
the  C2  system  could  not  be  viewed  as  a  single  C2  process.  On  the 
one  hand,  many  lateral  and  vertical  command  centers  were 
performing  the  same  C2  process  to  direct  weapons  under  their 
individual  control.  On  the  other  hand,  processes  that  provide 
support  to  the  C2  system  may  be  included.  These  processes  are: 

1.  Intelligence  (INTEL)  to  assign  meaning  to  observed 
activities  and  situations  and  forecasts  changes  in  the 
current  situation. 


2.  Crosstell  (XTEL),  a 
process  to  provide  for  s 
C2  system  to  support  dec 
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the  communications 
information  throughout 
their  implementation. 


the 
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FIGURE  14 


IFFN  TESTBED  STUDY:  TRANSFORM  ANALYSIS  OF  SINGLE  C2  NODE 
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3.  A  separate  "force  process"  is  performed  by  the  weapon 


system  and  its  munitions.  The  functions  of  the  force 


process  are  MANEUVER,  ACQUIRE,  ENGAGE  and  MISSILE  FLYOUT. 


Figure  15  shows  the  mapping  of  the  Generic  C2  process  functions 


to  the  air  defense  functions.  It  should  be  noted  that  the 


planning  function  is  performed  in  pre-real  time,  and  as  such,  is 


at  a  different  level  from  this  execution  level  air  defense 


process  model  loop. 


In  summary,  XTEL  and  INTEL  processes  interfaced  with  the  C2 


process  are  ultimately  linked  to  weapon  systems  which  perform 


the  mission.  These  processes  stand  alone  as  a  dynamic 


description,  apart  from  any  particular  command  node,  of  what  the 


C2  system  is  doing. 


It  should  be  noted  that  each  command  node  potentially  performs 


all  C2  functions  to  direct  actions  in  the  environment.  However, 


frequently  operational  concepts  which  distribute  functions 


between  command  nodes  (e.g.,  BFDCs  and  BNFDCs)  or  between 


command  nodes  and  weapon  systems  (e.g.,  CRC  and  fighter)  are 


employed.  When  this  ±j  the  case,  the  analysis  relating  to  the 


C2  process  and  the  other  related  processes  must  take  the  nodal 


distribution  of  functions  into  account.  The  requirement  for  the 


air  defense  system  is  described  in  further  detail  in  Module  4. 
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FIGURE  15 


IFFN  TESTBED  STUDY: 


MAPPING  OF  GENERIC  C2  TO  AIR  DEFENSE  PROCESS  FUNCTIONS 
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MODULE  4:  INTEGRATION  OF  STATICS  AND  DYNAMICS 

When  the  physical  entities  in  the  form  of  the  command  center, 
(first  component  of  Module  2),  person  and/or  the  machine  which 
performs  the  function,  (as  specified  in  Module  3)  are  added  to 
the  information  flow,  (second  component,  of  Module  2),  the  three 
dimensions  of  a  C2  system:  physical  entities,  structure  and 
process,  are  integrated. 

The  people  and  their  equipment  can  be  matched  to  the  structure. 
For  example,  a  battle  commander  performs  the  ASSESS  THREAT 
function.  He  is  supported  by  the  identification  officer,  whose 
subordinates  are  assignment  officers.  These  latter  officers 
implement  the  identification  officer's  decision  as  to  which 
targets  are  most  important  to  attack. 

The  equipment  consoles  may  be  viewed  as  capabilities  which  are 
implemented  by  reconfiguring  consoles  to  assign  targets  or 
control  weapons.  Using  DFD  to  describe  the  output  of  this 
matching  provides  a  graphic  depiction  of  the  integration  Module. 

The  DFD  concept  of  a  null  process  graphically  describes  the  C2 
functions  specifically  when  they  are  distributed  among  nodes. 
These  functions  can  not  be  duplicated,  although  they  can  be 
divided,  e.g.,  BFDC  allocates  BNFDC  and  BNFDC  allocates  weapons 
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The  null  process  indicates  that  only  one  execution  level  C2 
process  can  direct  a  specified  weapon  system,  although  its 
decisions  may  be  influenced  by  information  coming  from  other 
similar  processes,  e.g.,  indirect  ID  or  priorities  from  a 
higher  echelon  Figure  16  shows  a  representation  of  the  null 
process  by  DFDs. 


MODULE  5:  SPECIFICATION  OF  MEASURES 


The  measurement  strategy  couples  the  C2  process  to  the  force 
process  which  accomplishes  the  mission.  Since  the  IFFN 
processes  reflect  a  distributed  C2  system,  measures  which  show 
the  interaction  between  C2  processes  must  be  used.  Finally, 
these  interactive  measures  must  be  related  to  overall  mission 
measures . 


MODULE  6:  DATA  GENERATION 


It  is  expected  that  the  IFFN  testbed  itself  will  be  the  data 
generator  in  subsequent  iterations  of  this  research. 


MODULE  7:  AGGREGATION  OF  MEASURES 


This  Module  was  not  considered  in  this  analysis. 
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FIGURE  16 

IFFN  TESTBED  STUDY:  NULL  PROCESS  WITH  VERTICAL  C2  NODES 
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FEEDBACK  TO  THE  DECISION-MAKER 

IFFN  JTF  staff  and  the  IFFN  Testbed  Director,  Col.  Dave  Archino, 
participated  in  the  Workshop.  He  and  Maj.  Mike  Gray  of  the  IFFN 
JTF  had  previously  provided  direction  to  Maj.  Pat  Gandee  in  his 
preliminary  search  for  a  thesis  topic.  They  also  provided 
access  to  the  Testbed  library  and  other  documentation  to  Maj. 
Gandee . 

During  the  Pre-Workshop  preparation,  both  Maj.  Gandee  and  Dr. 
Sweet  briefed  the  Testbed  staff  on  the  planned  research.  When 
Maj.  Gandee's  thesis  was  completed,  he.  Dr.  Sweet,  and  Dr.  Joel 
Lawson,  a  major  participant  in  the  Air  Force  Tactical  Working 
Group,  briefed  the  Testbed  staff  on  the  results  of  the  research. 

Finally,  Dr.  Alexander  Levis  of  MIT  and  Earl  Hicks  of  AF/SA 
joined  Maj.  Gandee,  Dr.  Sweet,  Cpt.  Larry  Moss,  USA  and  NPS 
student,  Col.  Archino,  and  Maj.  Gray  to  discuss  an  article  for 
Signal  magazine  reporting  the  impact  of  the  MCES  on  the  IFFN 
testbed.  In  all  of  these  meetings,  a  standard  mode  of 
communication  of  findings  to  the  decision-makers,  as  well  as 
the  impact  of  the  IFFN  testbed  on  mission  effectiveness  and  its 
measurement,  using  MCES-guided  analytic  techniques,  were  the 
themes . 


MCES  &  Architectures 


78 


It  is  the  belief  of  all  concerned  that  Test  Series  2  will  show 


the  ultimate  benefit  of  these  interactions.  Data  Generation, 


following  the  work  done  in  the  various  reported  efforts,  will 


take  place  in  Test  Series  2.  Aggregation  and  subsequent 


reporting  will  be  taken  up  by  the  IFFN  JTF  staff.  The  recently 


completed  Test  Series  1  was  planned  without  the  insights 


provided  by  the  MCES,  the  Workshop  scoping,  cr  the  Gandee  thesis 


work.  However,  these  deliberations  were  input  to  the  planning 


of  Test  Series  2  as  well  as  to  the  interpretation  of  the  first 


series  test  data. 


Cpt.  Larry  Moss  will  continue  to  interact  with  the  IFFN  Testbed 


staff  in  the  attempt  to  assess  and  expand  the  potential  benefits 


of  the  MCES  into  the  performance  of  the  assigned  tasks. 


SUMMARY 


The  findings  of  this  application  were  accepted  by  IFFN  JTF 


management  and  will  be  input  to  future  work  on  this  C2 


architecture . 


This  research  led  to  the  following  lessons  learned  in  regard  to 


the  MCES  as  a  tool  for  evaluating  the  effectiveness  of  command 


and  control  systems: 


m 

tm 
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(1)  MCES  can  be  used  to  determine  the  necessary  data  to  be 
collected  in  a  test  series  for  an  operational  testbed  to 
answer  the  C2  design  problems  at  hand. 

(2)  MCES  can  be  effectively  applied  to  a  combat  system  with 
strong  C2  elements. 

(3)  MCES  can  be  used  to  test  alternative  operational 
concepts . 

(4)  MCES  provides  insight  into  delegated  and  distributed 
organizational  functions. 

(5)  This  application  lead  to  a  series  of  in  sights  and 
expansions  of  the  MCES: 

a) .  The  recognition  that  distributed  functions  require 
a  hierarchical  view  of  the  C2  process  model. 

b) .  The  indication  that  the  C2  process  Module  may  be 
applied  uniquely  in  any  given  problem,  depending  upon 
the  specific  requirements  of  the  problem. 

c) .  An  execution  level  process  is  defined  as  that  which 
occurs  when  the  C2  process  is  linked  directly  to  the 


weapon  system. 
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d) .  When  an  execution  level  C2  process  is  required  in 
the  problem,  the  plan  function  of  the  C2  process  model 
should  be  considered  in  pre-real  time. 

e) .  In  a  mission  level  analysis,  the  C2  Process  must  be 
related  to  other  processes,  namely: 

XTEL  for  sharing  information; 

INTEL  for  assessment  of  capabilities;  and 

FORCE  for  the  weapon  system  and  its  munitions. 

f) .  The  C2  Process  functions  as  given  in  any  problem 
may  be  mapped  to  the  generic  C2  Process. 

g) .  The  MCES  accommodates  and  demands  an  imbedded  set 
of  alternative  tools.  For  organizational  structure, 
this  research  suggested  DFDs  which  reflect  functions  at 
single  command  nodes,  distributed  command  nodes  and 
distributed  command  nodes  with  weapon  systems. 

h) .  An  explicit  Module  to  relate  the  statics  and 
dynamics  of  the  C2  system  together  is  necessary. 
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THE  SELECTED  ARCHITECTURES: 
SAC  OPERATIONAL  TESTING  STUDY 


OVERVIEW 

This  study  was  undertaken  by  Capt  Ingabee  Stone,  HQ  SAC/SICCP, 
with  the  cooperation  of  Mr.  Dan  Weis  of  ESI  Systems, 

Incorporated  (ESI).  ESI  is  under  contract  to  the  Defense 
Communications  Agency  to  provide  a  Qualified  Operational  Test 
and  Evaluation  (QOT&E)  plan  for  the  Strategic  Air  Command 
(SAC).  SAC  will  use  the  plan  to  evaluate  how  well  PACER  LINK  II 
aircraft  do  their  mission.  The  PACER  LINK  II  program  installs 
new  digital  communications  systems  into  the  EC-135  fleet. 

This  study  is  unclassified.  Where  classified  information  would 
add  to  the  understanding  of  the  problem,  references  are  stated. 
When  the  precise  description  of  operational  procedures  are 
sensitive,  unclassified  checklist  tasks  are  described. 

MODULE  1:  PROBLEM  FORMULATION 

The  Initial  Problem  Statement: 


Find  a  way  to  test  Post  Attack  Command  Control  System 
(PACCS)  operational  performance  onboard  PACER  LINK  II. 
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Limit  interference  with  the  primary  PACCS  mission. 

( 

I 

t 

Assumptions : 

The  mod  (modification)  block  systems  are  the  future  systems 

that  will  be  integrated  into  PACER  LINK  II.  Their  QOT&E 

must  also  be  integrated.  | 

I 

Testing  procedures  already  in  effect  within  the  military  j 

management  scheme  are  the  basis  of  the  QOT&E  test  plan. 

These  include  AFOTEC  directives. 

Assumptions  relative  to  the  actual  operational  environment 
(user  assumptions)  include  a  working  knowledge  of  the  Single 
Integrated  Operations  Plan  (SIOP)  and  the  flight  line  level 
operations  that  carry  out  the  SIOP. 

Level  of  Decision: 

What  life  cycle  phase  is  the  program  in? 

The  PACER  LINK  II  program  is  officially  a  Class  V 
upgrade  in  the  operational  phase  of  the  WWABNCP 
program.  A  Class  V  mod  is  a  change  in  equipment  to  an 


existing  program  (in  this  case,  the  existing  WWABNCP 
program)  including  a  change  in  capability. 
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The  PACER  LINK  II  program  is,  in  effect,  in  a 
procurement/production  status 


At  this  stage  of  the  life  cycle,  the  relevant 
contractors  provide  information  including  program 
management  reviews  (PMRs)  and  the  Contractor  Deliverable 
Requirements  List  (CDRLs)  associated  with  production. 

The  mod  block  systems  themselves  are  in  various  life 
cycle  phases.  Systems  in  the  concept  development  phase 
are  the  Nuclear  Detection  System  (NDS)  and  Advanced 
Narrowband  Digital  Voice  Transmission  (ANDVT)  system. 
Systems  in  the  design  phase  are  Ground  Wave  Emergency 
Network  (GWEN),  Military  Satellite  Communications 
(MILSTAR),  Miniature  Receive  Terminal  (MRT)  for  VLF/LF, 
and  the  100KW  Transmitter  and  Dual  Trailing  Wire  Antenna 
(DTWA)  systems  for  VLF/LF. 


Mod  block  systems  in 
Airborne  Launch  Cont 
secure  voice  phone, 
are  made  at  all  life 
LINK  II  analysis. 


production  include  Peacekeeper 
rol  System  and  the  STU  III  (C2) 

In  these  programs,  then,  decisions 
cycle  phases  which  affect  the  PACER 
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At  what  management  level  is  the  decision  maker? 

The  decision  maker  in  this  case  is  at  the  headquarters 
staff  level.  The  PACER  LINK  II  program  manager,  HQ 
SAC/DOCA,  will  staff  the  results  of  the  testing  and  make 
recommendations  to  correct  or  improve  the  remainder  of 
the  equipment  installations.  The  HQ  SAC/DO  will  act  on 
those  recommendations  and  direct  the  necessary  actions. 

Critical  Elements  To  Describe  The  System  Of  Interest: 

The  following  questions  were  formulated  for  the  problem  of 
testing  and  evaluating  the  new  PACER  LINK  II  C3  system: 

What  is  the  concept  of  operations  for  the  time  frame 
this  system  is  expected  to  operate?  Include  the  threat 
assessment  which  drove  the  new  system  development. 

Current  PACCS  operations  are  described  in  SACR  55-14 
and  SACR  55-45.  A  future  concept  of  operations  for 
a  SAC  airborne  command  post  is  contained  in  the 
Preliminary  System  Operational  Concept  for  the 
Survivable  Enduring  Command  Center  in  the  2010  time 


frame 


What  are  the  stated  system  specifications,  specifically 
the  technical  requirements? 

The  PACER  LINK  II  equipment  specifications  are 
contained  in  the  Air  Force  contract  with  ESI,  First 
level  (B-l)  specifications  are  available  from  the 
WWABNCP  program  manager  for  the  Digital  Airborne 
Intercommunications  and  Switching  System  (DAISS), 
the  equipment  interface  unit  (EIU),  the  electronic 
switching  matrix  (ESM),  the  attendant/maintenance 
control  unit  (ACU/MCU),  the  battle  staff  and 
operator  subscriber  station  unit  (SSU),  the  flight 
crew  SSU,  and  the  ground  line  interface  and 
signalling  unit  (GLISU). 

What  is  the  expected  WWABNCP  role  of  the  PACCS  aircraft 
as  nodes  in  the  new  system? 

The  expected  WWABNCP  role  of  PACER  LINK  II 
configured  aircraft  will  not  change  for  existing 
networks.  The  WWABNCP  taskings  for  the  PACCS  in 
these  networks  are  defined  in  EAP-JCS  Vol  VII,  the 
Force  Management  Communications  Plan,  and  the 
NMCS-DOD  Emergency  Communications  Plan. 
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The  operational  concepts  of  the  mod  block  programs 
may  modify  the  WWABNCP  taskings  in  the  future. 
There  are  written  SOCs  for  MILSTAR,  GWEN  and 
Peacekeeper . 


What  is  the  SAC  role  assigned  to  the  PACCS  within  the 
new  system? 


The  SAC  command  control  functions  of  the  PACCS  are 
contained  in  SACR  100-7  and  SACR  100-20  Vol  1. 


What  are  the  limits  of  the  airplane,  equipment  weight, 
electro-magnetic  interference  (EMI),  operator,  space, 
etc .  ? 


The  EC-135  aircraft  is  limited  to  12  hours  flight 
time  without  air  refueling,  and  72  hours  with 
refueling.  The  power  supply  is  400Hz.  Equipment 
weight  is  limited  by  the  amount  of  fuel  (and 
duration)  that  can  be  traded  for  equipment. 


EMI  between  onboard  systems  is  a  serious 
limitation.  It  is  managed  by  both  equipment  design 
and  frequency  assignment.  The  current  frequency 
plan  is  documented  in  SACR  100-7. 
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Presently  there  are  three  data  operators,  two  radio 
operators  and  two  inflight  maintenance  technicians 
in  the  communications  compartment.  With  existing 
capability  and  taskings,  they  are  able  to  handle 
traffic  flow.  However,  increased  data  rates  or 
voice  network  taskings,  without  automation,  could 
require  more  operators. 

What  are  typical  scenarios  and  what  actions  must  the 
operator  take  in  order  to  do  the  mission  in  that 
scenario? 

Typical  scenarios  are  suggested  by  the  SIOP.  They 
can  be  found  in  Battle  Staff  Training  Scenarios, 
GIANT  DRILLS,  POLO  HATs  and  GLOBAL  SHIELD  exercises. 

Operator  actions  for  the  set  of  tasks  required 
during  each  scenario  are  written  in  checklists, 
operator  reference  books  and  SACR  100-7,  Vol  I. 

2:  C2  SYSTEM  BOUNDING 


The  elements  of  the  PACER  LINK  II  world,  shown  in  Figure  17, 
represent  the  initial  boundary  of  the  decision-maker  on  whose 
behalf  the  MCES  is  employed.  These  elements  are: 
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FIGURE  17 

SAC  OPERATIONAL  TESTING  STUDY:  EXAMPLE  OF  SYSTEM  BOUNDING 
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PACCS  --  the  three  airborne  command  post  EC-135Cs  (ABNCP, 
EAUXCP,  WAUXCP),  the  three  airborne  launch  control 
EC-135A/Gs  (ALCC-1,  ALCC-2,  ALCC-3),  and  the  two  radio 
relay  EC-135Ls  (RR-1,  RR-2).  An  optional  member  of  the 
PACCS  is  the  CINCSAC  alert  aircraft,  another  EC-135C. 

PACER  LINK  II  equipment  --  the  new  digital  communications 
equipment  installed  in  the  EC-135  fleet. 

Battle  Staff  —  the  aircrew  members  which  perform  battle 
staff  functions  of  force  status,  emergency  actions, 
operations  controller,  operations  planner,  intelligence  and 
logistics . 

CCO  —  the  communications  control  officer. 

Comm  Team  —  the  radio  operators,  data  operators  and  radio 
maintenance  personnel. 

ROs  —  the  radio  operators  (RO-1  transmits  UHF,  RO-2 
transmits  HF). 

Other  nodes  in  C3  networks  --  Other  stations  on  the  ground 
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Remaining  sensors  —  Depending  on  the  post-attack  scenario, 
the  NORAD  and  associated  sensors  that  are  accessible  using 
the  communications  capability  provided  by  PACER  LINK  II 
systems . 

Returning  bombers  and  tankers  —  The  SAC  aircraft  which  have 
completed  their  mission  and  are  recovering  to  a  surviving 
base . 

Remaining  missiles  --  Minuteman  missiles  which  have  not 
been  launched. 

Reconstituted  forces  —  Aircraft  that  either  did  not  launch 
or  have  returned,  and  that  are  refueled,  reloaded  and  have 
crew3  ready  to  launch  again,  or  missiles  not  yet  launched 

NCA  —  The  National  Command  Authorities  or  designated 
successor . 

FEMA  --  The  Federal  Emergency  Management  Agency  which 
maintains  connectivity  with  the  NCA. 

POC/ET  and  SARTs  --  The  ground  mobile  relocation  teams  at 
the  SAC  headquarters,  Numbered  Air  Forces  and  units. 


MCES  &  Architectures 


91 


Other  WWABNCP  —  the  airborne  command  posts  of  the  other 
nuclear  SIOP  CINCs. 

Mod  Block  Systems  —  The  upgrade  programs  for  strategic  C2 
which  include  the  SAC  ABNCP  as  a  survivable  nod  in  those 
systems . 

Nuclear  effects  —  Uncertain  but  projected  to  degrade 
communications  for  C2  for  some  time. 

The  enemy  —  the  portion  of  enemy  forces  who  may  receive 
signals  from  the  actions  of  the  PACCS. 

An  interesting  observation  can  be  made  at  this  point.  Because 
of  the  exhaustive  nature  of  the  work  in  Module  1,  the  problem 
was  extremely  well  formulated.  Therefore,  application  of  Module 
2  becomes  straightforward  and  highly  graphically  oriented. 

It  must  be  noted  again  and  again,  that  the  various  steps  in  the 
MCES  are  highly  context  dependent.  Only  in  rare  cases  will 
their  execution  be  of  equal  difficulty  and  of  equal  detail.  As 
the  MCES  is  further  tested,  some  guidelines  in  this  regard  will 
appear.  For  instance,  generic  problems  will  require  more  detail 
in  formulation  and  in  bounding,  since  they  are  still  highly 
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Other  problems,  which  are  closer  to  fruition,  will  probably  take 
more  time  in  specification  and  aggregation,  as  their  solution 
are  defined  and  integrated. 

MODULE  3:  C2  PROCESS  DEFINITION 

The  SAC  airborne  major  functions  are:  Enduring  battle 
management;  Survivable  intelligence  fusion;  and  Capabilities 
planning  and  force  employment  support.  The  SAC  airborne  C2 
functions  are  shown  in  Figure  18. 

MODULE  4:  INTEGRATION  OF  STATICS  AND  DYNAMICS 

Given  the  functions  which  must  be  performed  onboard  the  SAC 
ABNCP,  this  Module  identifies  which  entity  (of  those  described 
in  the  C2  Bounding  Module)  performs  which  checklist  task  (of 
those  described  in  the  C2  Process  Definition  Module). 

The  following  diagrams  (Figures  19  and  20)  show  the  integration 
of  a  sample  task  performed  by  the  radio  operator  and 
communications  control  officer  to  accomplish  the  C2  function  of 
"Execution".  Figure  19  shows  the  procedural  flow  of  the  EAM, 
within  the  context  of  the  ABNCP  system  as  it  is  bounded  for  this 
discussion.  Figure  20  sets  up  a  matrix  that  integrates  the 
statics  and  dynamics. 
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FIGURE  18 

SAC  OPERATIONAL  TESTING  STUDY:  SAC  AIRBORNE  C2  FUNCTIONS 
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FIGURE  19 

SAC  OPERATIONAL  TESTING  STUDY:  PROCEDURAL  FLOW  OF  THE  EAM 
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Each  entity  is  associated  with  its  position  in  the  C2 
organization  (or  concept  of  operations)  and  the  generic  C2 
process  functions  (sense,  assess,  generate,  plan,  select  and 
direct).  From  these  diagrams  come  the  measures  which  will  be 
specified  in  the  next  MCES  Module. 

The  actions  taken  by  each  operator  to  perform  this  example  task, 
voice  relay  of  an  EAM,  are  documented  in  SACR  55-45,  and 
crewmember  checklists.  Procedures  for  the  remaining  tasks 
associated  with  each  C2  function  are  also  contained  in  those 
documents.  Only  one  task  is  shown  here  in  order  to  preserve  the 
unclassified  nature  of  this  paper. 

MODULE  5:  SPECIFICATION  OF  MEASURES 

Measures  may  be  extracted  from  the  checklist  procedures  of  each 
crew  position.  Since  this  analysis  deals  with  the  PACCS  as  a 
system  and  the  PACER  LINK  II  equipment  as  a  subsystem,  MCES 
suggests  that  the  appropriate  measures  are  measures  of  MOEs  and 
MOPs.  MOPs  in  this  case  are  the  frequently  used  measures  for 
communications  systems.  The  operators  who  collect  the 
measurements,  such  as  noise  readings,  voice  readability,  and 
gain,  will  compare  them  to  the  standard  readings  associated  with 
the  existing  aircraft.  In  this  way,  they  will  determine  if  the 
capability  of  PACER  LINK  aircraft  equals  that  of  the 
non-modified  aircraft. 
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MOEs  for  this  study  are  similar  to  those  used  during  POLO  RAT 
evaluations.  These  measure  the  connectivity  at  the  system  level 
using  the  criteria  of  yes-it-works/no-it-doesn * t-work .  This  is 
acceptable  for  this  case  because  the  purpose  of  the  Class  V 
modification  to  the  aircraft  is  to  retain  the  capability  of  the 
old  aircraft,  with  only  minor  additional  capability.  MOEs  for 
the  additional  capability  are  more  directly  related  to  the 
quantified  measures  of  performance  previously  identified. 

Figure  21  summarizes  the  measures  which  are  applicable  to  the 
sample  task  of  voice  relay  of  an  EAM.  The  MOEs  are  extracted 
from  the  ESI  QOT&E  plan  for  PACER  LINK  II  aircraft.  Although 
the  plan  uses  the  term  "MOE"  throughout,  the  figure  above 
indicates  which  are  MOPs  and  which  are  MOEs  as  defined  in  the 
MCES. 


The  MOEs  are  defined  as: 

MOE  2.1  The  modified  communication  systems  on  the  PACER 
LINK  modified  EC-135  are  able  to  support  the  operational 
airborne  mission  requirements  of  SAC. 

MOE  2.1.3  The  DAISS  generates,  receives,  interprets  and 
converts  the  required  analog  and  digital  signaling  (control 
signals) . 
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MOE  2.1.10  The  DAISS  classmarking  of  the  radio  operators 
SSU  is  functional. 

MOE  2.1.32  The  radio  operator  can  configure  and  perform  the 
AM-dropout  function. 

MOE  2.1.47  The  radio  operator  can  conference  and  perform 
the  HF  transmit  function. 

MOE  5.1  PACER  LINK  modified  EC-135s  are  interoperable  with 
the  ground/airborne  resources  of  the  JCS  and  the 
unified/specified  commands. 

MOE  5.1.10  The  PACER  LINK  modified  aircraft  enables  SAC 
operators  to  perform  their  roles  as  outlined  in  the  EAP-JCS 
Vol  V. 

MODULE  6:  DATA  GENERATION 

Data  will  be  generated  during  a  series  of  test  flights  designed 
to  simulate  the  scenarios  in  which  the  EC  135  is  expected  to 
fly.  Onboard  each  test  flight,  data  will  be  recorded  by  highly 
qualified  crew  members  operating  the  command  and  control  systems 
and  networks  as  they  would  in  an  operational  mission.  Data 
collection  logs  will  approximate  real  world  logs  as  closely  as 


is  feasible 
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These  test  flights  will  closely  follow  the  POLO  HAT  scenarios 
used  to  evaluate  the  EC-135  role  in  strategic  command  and 
control . 

MODULE  7:  AGGREGATION  OF  MEASURES 

This  Module  of  the  MCES  will  analyze  the  data  collected  during 
data  generation,  aggregate  appropriate  measures  and  determine 
whether  this  format  for  testing  has  demonstrated  the  operational 
capability  of  PACER  LINK  II  aircraft, 

FEEDBACK  TO  THE  DECISION  MAKER 

The  product  of  this  iteration  of  the  MCES  is  a  focused, 
objective  QOT&E  plan  to  be  used  by  the  PACER  LINK  II  program 
manager  to  test  and  evaluate  operations  on  board  the  newly 
configured  aircraft. 

In  this  plan,  the  test  and  evaluation  will  be  done  manually,  by 
observers  using  checklists  and  data  collection  paperwork. 
Examples  drawn  from  this  QOT&E  plan  are  presented. 

The  entire  plan  will  be  delivered  to  the  Defense  Communications 
Ag  ency  for  SAC  at  the  end  of  this  fiscal  year.  The  insights 
provided  herein,  using  the  MCES,  were  incorporated  by  the 
contractor,  ESI,  in  the  overall  QOT&E  task. 
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This  analysis  has  been  accomplished  through  the  Module  5: 
Specification  of  Measures.  The  remaining  Modules  will  be 
accomplished  when  the  first  PACER  LINK  II  aircraft  is  delivered 
to  SAC  in  early  1987. 

SUMMARY 

The  findings  of  this  application  were  accepted  by  HQ  SAC/DOCA 
and  input  to  the  PACER  LINK  QOT&E. 

Insights  derived  from  the  analysis  were  incorporated  by  the 
contractor,  ESI,  in  its  overall  QOT&E  task. 

A  significant,  albeit  peripheral,  finding  from  Capt.  Stone's 
work  is  the  vindication  of  the  thesis  that  a  staff  officer,  new 
to  an  assignment,  who  has  been  trained  in  the  MCES,  may  enter 
the  analysis  process  midstream  effectively.  Capt.  Stone  was 
able  to  bring  heiself  "up  to  speed"  in  her  new  assignment  by 
using  the  MCES  guidance  to  focus  on  the  essential  components  of 
the  volume  of  materials  available  to  provide  background  to  the 
PACER  LINK  QOT&E.  As  a  result,  she  was  able  in  a  relatively 
short  time  period,  to  be  a  highly  productive  member  of  the  test 
team.  This  spin-off  finding  has  vast  training  implications  to 
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This  research  led  to  the  following  lessons  learned  in  regard  to 
the  MCES  as  a  tool  for  evaluating  the  effectiveness  of  command 
and  control  systems: 

(1)  MCES  can  be  used  to  determine  the  necessary  data  to  be 
collected  in  an  operational  test  series  to  answer  the  C2 
integration  problems  at  hand. 


(2)  MCES  can  be  effectively  applied  to  a  communication 
system. 

(3)  This  application  lead  to  a  series  of  insights  and 
expansions  of  the  MCES: 

a).  A  standardized  set  of  questions,  entitled 
"Standard  Report  Format"  was  developed  for  Module  1, 
(See  Figure  22.) 


b) .  A  graphic  representation  of  selected  aspects  of 
system  statics  was  developed,  i.e.,  information  flow 
represented  "structure",  and  platforms  were  the 
designated  "physical  entities". 

c) .  Standard  test  terminology  was  shown  to  be  mappable 
to  the  MCES  terminology,  thus  expanding  the  potential 
commonality  of  usage  of  definitions. 


The  Initial  Problem  Statement: 

Assumpt ions : 

Level  of  Decision: 

What  life  cycle  phase  is  the  program  in? 

At  what  management  level  is  the  decision  maker? 

Critical  Elements  To  Describe  The  System  Of  Interest: 
Problem  Specific  Questions,  e.g., 

1.  What  is  the  concept  of  operations  for  the  time 
frame  in  which  this  system  is  expected  to 
operate.  Include  the  threat  assessment  which 
drove  the  new  system  development. 

2.  What  are  the  stated  system  specifications, 
specifically  the  technical  requirements? 

3.  What  is  the  expected  WWABNCP  role  of  the  PACCS 
aircraft  as  nodes  in  the  new  system? 


FIGURE  22 


STANDARDIZED  REPORT  FORMAT  FOR  MODULE  1:  PROBLEM  FORMULATION 
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Critical  Elements  To  Describe  The  System  Of  Interest:  (Cont'd.) 

4.  What  is  the  SAC  role  assigned  to  the  PACCS 
within  the  new  system? 

5.  What  are  the  limits  of  the  airplane,  equipment 
weight,  electro-magnetic  interference  (EMI), 
operator,  space,  etc.? 

6.  What  are  typical  scenarios  and  what  actions 
must  the  operator  take  in  order  to  do  the  mission 
in  that  scenario? 


FIGURE  22  (Concluded) 


STANDARDIZED  REPORT  FORMAT  FOR  MODULE  1:  PROBLEM  FORMULATION 
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THE  SELECTED  ARCHITECTURES: 


GLOBAL  SCALE  WARFARE  C2  ARCHITECTURE  (SUPERCINC)  STUDY 


OVERVIEW 


This  study  was  undertaken  with  primary  support  of  the  Naval 


Postgraduate  School,  OSD  and  OJCS.  Dr,  Ricki  Sweet  was 


Principal  Investigator,  Capt.  Kevin  Briggs  was  the  lead  analyst 


for  this  research.  Dr.  Tom  Rona  provided  technical  and 


scientific  advise  on  behalf  of  OSD.  OSD  will  use  this  research 


to  provide  preliminary  scoping  of  the  conceptual 


development/definition  phase  of  subsequent  work  on  the  C2 


architectural  requirements  for  SuperCINC.  This  study  is 


unclassified . 


As  presented  in  this  report,  the  SuperCINC  problem  significantly 


expands  the  Air  Force  Strategic  Problem  from  the  Workshop  and  is 


a  rather  detailed  scoping  for  the  problem. 


MODULE  1:  PROBLEM  FORMULATION 


The  Initial  Problem  Statement: 


The  initial  problem  was  to  develop  a  command  and  control 


concept  to  exercise  operational  command  responsibility  above 
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the  CINC  level  during  global-scale 
circa  2000  to  2020  timeframe.  This 
referred  to  as  SuperCINC. 

The  SuperCINC  command  and  control  doctrine  and  capability  is 
assumed  as  necessary  to  fulfill  the  role  of  orchestrating 
the  operational  command  of  global-scale  warfare,  according 
to  an  OSD  Memorandum  for  the  Deputy  Assistant  Secretary  of 
Defense  (DASD/C3)  titled  "Large  Scale  Challenges  to  C3I," 

"At  this  time,  there  is  no  satisfactory  concept  to  provide 
for  the  C&C  support  required  to  exercise  operational  command 
responsibility  above  the  CINC  level  when  operations  involve 
the  integrated  activities  of  several  CINCs". 

"The  structure,  when  fully  brought  up  to  the  level  necessary 
to  satisfy  the  design  objectives,  will  be  adequate  to 
support  operations  that  are  essentially  circumscribed  within 
the  responsibility  of  individual  CINCs.  It  will  not  satisfy 
the  operational  needs  of  global-scale  warfare  (nuclear  or 
other)  when  these  involve  operations  that  transcend  the 
currently  defined  purviews  of  the  Specified  and  Unified 
Commands"  (page  6,  OSD  memorandum). 


warfare  operations  in  the 
concept  is  herein 
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Assumptions : 

1.  Operational  command  refers  to  those  functions  of 
command  involving  the  composition  of  subordinate  forces, 
the  assignment  of  tasks,  the  designation  of  objectives  and 
the  authoritative  direction  necessary  to  accomplish  the 
mission.  It  does  not  include  such  matters  as 
administration,  discipline,  internal  organization,  and  unit 
training  except  when  a  subordinate  commander  requests 
assistance.  (JCS  Pub  1) 


2.  For  the  purposes  of  this  monograph,  global-scale 
warfare  is  defined  as  conventional  and/or  nuclear 
operations  conducted  by  the  United  States,  and  possibly  in 
concert  with  its  allies,  directed  concurrently  against  major 
enemy  forces  in  more  than  one  unified,  specified,  or  joint 
task  force  commander's  area  of  responsibility. 

3.  A  unified  command  is  "a  command  with  a  broad 
continuing  mission  under  a  single  commander  and  composed 
of  significant  assigned  components  of  two  or  more 
Services,  and  which  is  established  and  so  designated  by 
the  President,  through  the  Secretary  of  Defense  with  the 
advice  and  assistance  of  the  Joint  Chiefs  of  Staff,  or, 
when  so  authorized  by  the  Joint  Chiefs  of  Staff,  by  a 
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commander  of  an  existing  unified  command  established  by 
the  President” . (JCS  Pub  1) 

4.  A  Joint  Task  Force  (JTF)  is  a  force  composed  of 
assigned  or  attached  elements  of  the  Army,  the  Navy,  or 
the  Marine  Corps,  and  the  Air  Force  or  two  or  more  of 
these  Services,  which  is  constituted  and  so  designated  by 
the  Secretary  of  Defense  or  by  the  commander  of  a  unified 
command,  a  specified  command,  or  an  existing  joint  task 
force.  (JCS  Pub  1) 

Threat:  It  is  plausible  that  once  a  major  conflict 

starts  in  one  theater  of  operations,  the  United  States 
may  face  yet  another  major  concurrent  conflict  in  one 
or  more  additional  geographic  regions.  Presented  below 
is  one  such  scenario.  This  scenario  is  proposed  as  an 
unclassified  strawman  to  both  exercise  the  methodology 
and  scope  the  analysis,  the  details  of  which  will  be 
classified . 

Scenario:  There  are  two  components  to  the  scenario,  a 

conventional  first  phase  and  a  continuation  phase 
during  which  nuclear  war  begins. 
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Scenario  Assumptions: 


1.  SDI  systems  will  be  operationally  deployed 


during  the  circa  2000-2020  timeframe. 


2.  Current  alliance  and  treaty  structures  still 


exist . 


Level  of  Decision: 


What  life  cycle  phase  is  the  program  in? 


This  analysis  represents  the  definition  phase  of  the 


development  of  an  architectural  concept  for  SuperCINC. 


At  what  management  level  is  the  decision  maker? 


This  is  a  mission  level  analysis.  The  primary  missions 


of  interest  for  the  SuperCINC  problem  involve 


deterrence  and  escalation  control. 


Critical  Elements  To  Describe  The  System  Of  Interest : 


Most  of  the  missions  of  interest  involve  processes  of 


interaction  between  the  SuperCINC  C2  system  and  the  friendly 


or  enemy  civil  and  military  leadership/commanders, 
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Figures  23  and  24  illustrate  the  systems  of  interest  and 
some  of  these  interaction  missions. 

MODULE  2:  C2  SYSTEM  BOUNDING 

The  physical  entities  of  the  SuperCINC  are  assumed  to  consist  of 
the  primary  and  alternate  command  and  control  architectures 
extending  to  the  subordinate  CINCs  as  well  as  additional  C2 
architectures  (to  include  doctrines  and  physical  systems)  unique 
to  the  SuperCINC  required  to  interface  with  friendly  and  enemy 
civil  and  military  leadership. 

Although  ultimately  both  procedures  and  concepts  of  operation 
would  be  described  in  detail  with  additional  research,  the 
scoping  has  focused  upon  the  specification  of  the  organizations 
involved  and  upon  information  flow  patterns.  The  organizations 
involved  in  the  conventional  scenario  are:  NCA,  OSD,  JCS,  NSA, 
CIA,  DIA,  NSC,  the  State  Department,  CINCEUR/SACEUR ,  CINCENT, 
CINCSAC,  CINCMAC,  CINCRED,  and  CINCLANT  as  well  as  the  relevant 
enemy  and  friendly  civilian  and  military  leadership.  For  the 
purposes  of  discussion,  the  nuclear  scenario  participants  will 
also  include  CINCSPACE,  CINCSPACECOM ,  FEMA,  CINCPAC  and 
CINCNORAD . 
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FIGURE  23 


GLOBAL  SCALE  WARFARE  C2  ARCHITECTURE  (SUPERCINC)  STUDY! 
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FIGURE  24 

GLOBAL  SCALE  WARFARE  C2  ARCHITECTURE  (SUPERCINC)  STUDY: 
INTERACTION  SYSTEMS  AND  MISSIONS 
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MODULE  3:  C2  PROCESS  DEFINITION 


For  the  purposes  of  this  scoping  the  internal  functions  of  the 
generic  C2  process  are  taken  as  given  and  the  focus  is  upon:  (1) 
the  environmental  "initiator"  of  the  C2  processes,  which  result 
from  a  change  from  the  desired  state  and  (2)  the  input  to  and 
output  from  the  internal  C2  process.  For  the  environmental 
initiator,  enemy  strategy,  concepts,  tactics,  and  doctrine  in 
terms  of  maximizing  deterrence  and  escalation  control  are 
pre-cursor  requirements  for  development  of  SuperCINC 
capability.  For  input/output  (information  flow),  a  functional 
perspective  is  taken. 


FEEDBACK  TO  DECISION  MAKER 


The  remaining  Modules  are:  (1)  C2  Process  Definition;  (2) 
Integration  of  Statics  and  Dynamics;  (3)  Specification  of 
Measures;  (4)  Data  Generation;  and  (5)  Aggregation  of  Measures. 
Therefore,  in  the  strictest  sense,  feedback  to  Decision-maker 
has  not  been  accomplished. 


SUMMARY 


The  SuperCINC  problem  was  carried  through  the  first  two  Modules 
of  the  MCES  in  some  detail.  Thereafter,  resource  constraints 
were  imposed  so  that  subsequent  scoping  was  not  possible. 
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However,  the  work  accomplished  represented  a  firm  beginning  to 
analysis  of  this  topic.  It  is  important  to  note  that  the 
Workshop  scoping  of  the  Air  Force  Strategic  problem  represented 
approximately  24  man  days  of  effort.  The  subsequent  activity 
represents  approximately  12  additional  man  days.  In  general, 
studies  which  identify  (1)  the  scenario  of  interest  in  the 
problem,  (2)  the  actors/systems  and  (3)  the  information  flow 
require  between  5  and  12  man  months  of  effort.  Thus,  this 
approach  resulted  in  savings  of  from  3  to  10  man  months. 

The  SuperCINC  analysis  as  completed  will  be  used  in  the  SDI 
Workshop  mentioned  above.  It  will  provide  a  description  of  the 
necessary  information  flow  patterns.  In  addition,  this  work 
will  be  supportive  of  the  overall  SDI  concerns  with  deterrence 
and  escalation  control. 

The  findings  of  this  application  were  accepted  by  OSD  to  provide 
preliminary  problem  definition. 

This  research  led  to  the  following  lesson  learned  in  regard  to 
the  MCES  as  a  tool  for  evaluating  the  effectiveness  of  command 
and  control  systems: 

MCES  can  be  used  in  the  conceptual  development  phase  of  C2 
systems  and  architectures  by  providing  a  top  down  approach 
which  focuses  upon  essential  elements  of  the  problem. 
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This  application  lead  to  the  following  insights  and  expansions 
of  the  MCES: 

1) .  There  must  be  a  redesignation  of  Module  1  from  its 
focus  on  Analysis  Objectives  to  the  more  global  issue  of 
Problem  Formulation. 

2) .  Both  the  assumptions  intrinsic  to  the  analysis  and  the 
scenario(s)  under  which  the  findings  will  hold  must  be  made 
explicit . 

3) .  The  environmental  initiators  to  the  C2  Process  must  be 
emphasized . 

4) .  Both  the  input  and  the  output  from  the  C2  Process  must 
be  taken  into  account. 

5) .  "Plan"  may  be  classified  as  a  "Pre-Real  Time"  activity. 

6) .  Interoperability  issues  requires  the  identification  of 
the  actors  and  systems  which  make  up  the  architecture  of 


concern 
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CONCLUSIONS 

The  MCES,  as  developed  through  the  three  successive  meetings 
described,  has  provided  the  community  with  a  theoretical 
framework  for  top  level  problem  specification.  It  has  also 
provided : 

A  management  support  with  decision  support  system  to  do 
architectural  comparisons; 

A  systems  theory  approach  to  an  integrated  view  of  the  C2 
system/architecture  being  evaluated; 

A  vehicle  for  the  integration  of  disparate  tools; 

A  standard  vocabulary  which  is  beginning  to  be  accepted  and 
used  within  the  analytic  community; 

The  guidance  for  analytic  studies.  It  was  this  latter  role 
which  was  exercised  in  the  architectural  efforts  reported 
herein . 

Testing  the  MCES  in  the  fire  of  real  world  problems  dramatically 
pointed  out  the  strengths  of  the  structure  as  well  as  the  less 
well  developed  aspects. 
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In  some  respects,  the  MCES  has  yet  to  reach  maturity.  In 
others,  these  studies  have  provided  an  expanded  set  of  imbedded 
concepts.  This  section  attempts  to  summarize  where  the 
"discipline"  of  the  MCES  stands.  It  should  be  contrasted  with 
the  more  generic  description  presented  above. 

All  of  the  Modules  are  important.  If  measures  are  to  be 
developed  and  used,  the  key  Module  is  Specification  of 
Measures.  Everything  else  is  geared  to  support  the  relevant  set 
of  measures  to  be  developed.  In  the  MCES,  the  "E"  stands  for 
Evaluation,  Evaluation  through  Measurement. 

Nevertheless,  application  studies  within  the  concept 
development/def inition  stage  are  highly  dependent  on  the  first 
four  Modules.  It  is  through  these  Modules  that  responsibilities 
are  established  from  the  standpoint  of  organizations  working  the 
problem,  operational  entities  using  the  C2  systems/architectures 
and  agencies  participating  in  program  management.  Operational 
studies,  including  testing,  emphasize  the  last  four  Modules. 

Both  design  and  acquisition  evaluations  are  focused  primarily  in 


the  last  three  Modules. 


In  all  cases,  the  first  Modules  are  essential.  Preliminary 


materials  representing  these  early  Modules  are  ideally  made 


available  to  projects  which  require  them  as  input. 


rm 

wM' 


■  w  W 


'  \,mv 


MCES  &  Architectures 


118 


In  those  cases,  the  MCES  provides  a  checklist  for  the 
organization  of  the  massive  data  provided  and  as  an  oversight 
review  tool  to  identify  gaps  in  the  information  needed  to 
proceed  further.  Therefore,  the  MCES  is  used  deferentially  to 
emphasize  the  appropriate  actions  needed  for  the  application  at 
hand . 

Module  1  describes  what  the  decision-maker's  analysis  objectives 
are  from  the  standpoint  of  (1)  the  life  cycle  of  a  military  (C2) 
system,  and  (2)  the  level  of  analysis  prescribed.  Both  the 
appropriate  scenarios  and  the  assumptions  underlying  the 
evaluation  are  made  explicit. 

From  the  standpoint  of  the  life  cycle  phases,  concept 
development/definition  is  the  focus  of  the  SuperCINC  and  SDI 
problems.  The  design  phase  is  represented  by  the  Navy  Battle 
Group  problem.  The  acquisition  phase  is  not  included  in  this 
work,  although  the  initial  support  for  this  type  of  standardized 
analysis  approach  came  from  those  decision-makers  in  the 
community  who  worked  in  the  acquisition  realm.  Finally,  the 
operational  phase  is  represented  by  both  the  IFFN  JTF  and  the 
SAC  problem.  Both  of  these,  of  course,  are  centered  upon 
testing . 
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The  level  of  the  analysis  includes  only  mission  (SuperCINC, 

IFFN,  Navy  Battle  Group,  and  the  SDI  problems)  and  subsystem 
(SAC)  level  studies.  Figure  25  shows  the  extent  of 
generalizability  of  the  study  results. 

For  the  first  Module,  the  questions  given  in  the 
software/analyst  dialogue  example  help  to  clarify  the  implicit 
issues  involved. 

The  problem  statement  is  then  used  in  the  second  Module  to  bound 
the  C2  system  of  interest.  The  definitions  used  focus  upon  two 
parallel  relationships.  The  first  shows  the  system  as  made  up 
of  sub-systems,  within  a  force  all  of  which  are  within  an 
environment.  These  define  the  problem  space.  Outside  the 
problem  space  is  the  "rest  of  the  world".  The  second  shows  the 
elements  aggregated  to  sub-systems,  which  become  systems,  which 
integrate  to  architectures.  The  characterization  used  depends 
upon  the  best  representation  for  the  problem  of  interest.  In 
either  case,  it  must  reflect  both  physical  entities  and 
structure.  This  characterization  may  be  exhaustive,  covering 
all  aspects  of  the  physical  entities  and  structure,  as  defined 
above,  or  selective  of  aspects  of  each,  as  shown  in  Figure  26. 


None  of  the  studies  reported  addressed  all  aspects  of  these  two 
system  statics  components.  All  took  a  Chinese  menu  approach. 
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For  the  Navy  Battle  Group  problem,  physical  entities  were 
represented  by  equipment,  whereas  structure  was  represented  by 
organizations.  For  the  IFFN  problem,  the  focus  was  upon  both 
the  equipment  and  the  operational  concepts  as  related  to  command 
centers,  identification  sources,  and  weapon  systems  when  they 
perform  C2  functions.  The  SAC  problem  focussed  upon  equipment, 
including  facilities  as  exemplified  by  platforms,  and 
information  flow.  The  SuperCINC  problem  defined  the  physical 
entities  as  consisting  of  the  primary  and  alternate  command  and 
control  architectures  extending  to  the  subordinate  CINCs  and  the 
structure  as  involving  the  specification  of  the  organizations 
involved  and  upon  information  flow  patterns.  Thus  the  physical 
entities  -  equipment,  software,  people  and  their  associated 
facilities,  and  structure  -  organization,  concepts  of  operation 
(including  procedures  and  protocols)  and  information  flow 
patterns  were  only  marginally  represented  by  these  studies,  as 
shown  in  Figure  27. 

The  generic  C2  process  component  of  the  system  is  applied  in  the 
third  Module.  This  concept  forces  attention  on  (1)  the 
environmental  "initiator”  of  the  C2  process,  which  result  from  a 
change  from  the  desired  state;  (2)  the  internal  C2  process 
functions  that  characterize  what  the  system  is  doing,  (sense, 
assess,  generate,  select,  plan,  and  direct);  and  (3)  the  input 
to  and  output  from  the  internal  C2  process. 
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C2  SYSTEM  BOUNDING;  WHAT  THE  STUDIES  INCLUDED 
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Both  the  IFFN  study  and  the  SuperCINC  studies  explicitly  debated 
the  generic  orientation,  (2). 

The  SuperCINC  focussed  upon  the  environmental  initiator,  i.e., 
primarily  the  threat  to  the  C2  system  which  any  deficiency 
represents.  In  addition,  attention,  was  also  directed  toward  the 
input  and  output  of  the  C2  process.  This  was  achieved  by  taking  a 
"black  box"  approach,  similar  to  that  used  in  communications 
systems  analysis.  This  proved  to  be  a  very  useful  tool  in 
describing  both  information  flow  and  transformations. 

Both  SuperCINC  and  the  IFFN  study  moved  "Plan"  from  the  focus 
taken  by  the  generic  approach.  The  studies  viewed  plan  as  the 
first  activity  in  the  C2  Process.  Indeed,  plan  may  be  referred  to 
as  the  "pre-real-time"  activity  of  command  and  control. 

The  IFFN  study  suggested  that  the  C2  Process  must  be  related 
to  other  processes  at  least  in  a  mission  level  analysis. 

The  XTEL  process  was  introduced  to  support  sharing  of 
information  which  occurs  on  a  system  level. 

The  INTEL  process  indicates  that  commanders  use  information 
from  their  own  sensors,  feedback  from  the  forces  and 
interface  with  a  separate  intelligence  process  to  develop 
perceptions  about  the  enemy  and  friendly  capabilities. 
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This  intelligence  process  also  interfaces  with  the  C2 
process . 

Since  the  C2  system's  purpose  is  to  direct  some  force  within 
the  environment,  the  process  which  directly  controls  weapon 
systems  is  defined  to  be  an  execution  level  C2  process. 

A  separate  "force  process"  is  performed  by  the  weapon  system 
and  its  munitions. 

For  those  studies  where  the  generic  approach  was  taken,  the 
functions  of  the  C2  process  for  a  given  problem  were  identified 
and  mapped  to  the  generic  C2  process  loop.  When  this  mapping  was 
completed,  it  embedded  the  terminology  in  terms  of  the  canonical 
six  C2  process  functions.  For  those  using  this  approach  to  the  C2 
Process,  the  link  to  a  body  of  theory  relating  to  C2  Process  and 
its  measurement  is  begun  to  be  made. 

The  fourth  Module  relates  the  C2  processes,  physical  entities  and 
structure.  Techniques  such  as  DFDs  and  Petri  Nets  are  directed  at 
information  flow  in  the  C2  process.  A  matrix  approach  has  been 
useful  in  integrating  the  three  components  and  relating  them  to  an 
hierarchical  view  of  systems,  i.e.  ranging  from  elements  to 


architectures 
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This  approach  leads  more  directly  to  measures  that  will  be 
descriptive  of  the  C2  system  as  a  whole,  whereas  considerable 
interpolation  is  necessary  with  both  DFD  and  Petri  Nets. 

The  SuperCINC  study  ended  prior  to  this  Module.  The  IFFN  study 
employed  DFD  specifically  determining  the  hierarchical 
relationships  between  the  individual  C2  functions.  So  used,  DFDs 
reflect  an  organizational  structure,  which  could  reside  in  a 
single  node  or  be  distributed  between  command  nodes  or  between 
command  and  weapon  nodes.  Thereafter,  the  physical  entities  which 
perform  functions  are  mapped  to  the  output  from  the  functions.  As 
a  result,  the  IFFN  study,  with  substantial  analysis,  used  DFDs  to 
reflect  the  integration  of  the  statics  and  the  dynamics  of  the  C2 
system/architecture.  Indeed,  it  was  this  study  which  first 
pointed  out  the  requirement  in  the  MCES  for  such  an  explicit 
Module . 

The  Navy  Battle  Group  study  and  the  SAC  study  took  the  matrix 
approach.  The  matrix  approach,  as  indicated  above,  leads  to  a 
particular  measurement  philosophy.  The  matrix  describing  the  C2 
architecture  is  completed  at  the  appropriate  level  of  detail.  One 
or  more  measures,  suitable  to  both  the  problem  at  hand  and  the 
data  generator  available,  are  identified.  These  measures  are  then 
taken  as  the  critical  or  minimum  essential  set  of  measures  for  the 
problem  at  hand. 
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Other  techniques,  such  as  Petri  Nets,  may  be  employed  to  derive  a 
complete  set  of  relevant  measures,  which  are  then  subjected  to 
further  scrutiny.  These  may  be  compared  to  a  set  of  criteria 
measures,  reducing  the  exhaustive  set,  often  in  the  thousands  of 
measures,  to  a  more  manageable  set.  The  IFFN  study  approach  used 
techniques  of  this  type. 

Regardless  of  the  technique  chosen,  this  Module  results  in  the 
selection  of  a  final  set  of  measures.  These  may  be  classified  as 
to  their  level  of  measurement,  i.e.,  MOPs,  MOEs,  or  MOFEs,  and  as 
a  result,  to  the  kind  of  conclusion  that  can  be  drawn  using  them 
in  an  analysis. 

The  generation  of  values  for  these  measures  is  addressed  by  the 
next  Module.  Here,  one  of  several  types  of  data  generators  is 
selected.  The  values  to  be  associated  with  the  measures 
determined  above  are  the  resultant  output  of  the  implementation  of 
this  Module. 

The  Navy  Battle  Group  study  reported  within  this  report  completed 
its  proposal  with  this  Module,  although  Vol  III  reports  a  second 
study  under  this  funding  which  included  the  aggregation  Module. 

The  first  study  employed  exercise  data  for  the  generation  Module, 
whereas  the  latter  used  a  simulation  model,  SCSS,  to  generate  (and 
aggregate)  the  values  for  the  measures. 
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Both  the  IFFN  study  and  the  SAC  study  will  use  test  data,  the 
former  from  the  testbed  and  the  operational  testing  study  from 
that  environment.  For  this  report,  no  experiments  were  used  as 
data  generators.  All  the  data  generators  were  selected  as 
available  and  appropriate  to  generate  the  values  for  the 
predetermined  measures.  This  flexibility  of  the  MCES  to 
accommodate  (or  reciprocally  to  be  accommodated  by)  a  variety  of 
data  generators  was  clearly  shown  in  this  research  effort. 

The  final  Module  addresses  the  issue  of  how  and  when  to  aggregate 
the  measures.  The  levels  of  the  decisionmaker,  his  needs  and 
directions  for  the  analysis  determine  the  appropriate  format. 

Such  a  format  may  be  a  set  of  algorithms,  summarizing  all  the  data 
quantitatively;  a  matrix  of  both  quantitative  and  qualitative 
information;  or  a  description  of  the  results  of  the  analysis, 
presented  in  executive  summary  format.  The  implementation  of  this 
Module  provides  the  analysis  results  tailored  to  address  the 
problem  initially  posed  by  the  decisionmaker,  and  further 
qualified  in  the  Problem  Formulation  Module.  Although  none  of  the 
studies  reported  herein  have  directly  addressed  this  issue,  it  is 
clear  that  the  level  of  aggregation,  the  life  cycle  of  the 
military  system,  and  the  decisionmaker’s  organizational 
responsibilities  will  interact. 
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It  is  the  opinion  of  the  analysts  concerned  that  this  effort  has 
made  considerable  advances  in  the  realm  of  the  evaluation  of  C2 
systems  and  architectures.  It  is  with  the  expectation  that  the 
community  will  judge  likewise  and  will  have  the  interest  and  need 
to  apply  the  MCES  for  his  problem  area  that  this  document  was 
written . 
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ACRONYMS 

AAW  Anti-Air  Warfare 

ABNCP  Airborne  Command  Post 

ACU/MCU  Attendant/maintenance  control  unit 

AFOTEC  Air  Force  Operational  Test  and  Evaluation  Center 

AF  Air  Force 

ALCC  Airborne  launch  control 

ANDVT  Advanced  Narrowband  Digital  Voice  Transmission  system 

ASUW  Anti-Surface  Warfare 

ASUWC  Anti-Surface  Warfare  Coordinator 

ASW  Anti-Submarine  Warfare 

ATAF  Allied  Tactical  Air  Force  (NATO) 

BDG  Brigade  Fire  Detection  Center 

BFIM  Battle  Force  Information  Management 

BM  Battle  Management 

BNFDC  Battalion  Fire  Detection  Center 

BVR  Beyond  visual  range 

CAI  Computer  Aided  Instruction 

C&C  Command  and  Control 

CCO  Communications  control  officer. 

CDRL  Contractor  Deliverable  Requirements  List 

CIA  Central  Intelligence  Agency 

CINC  Commander  in  Chief 

CINCENT  Commander  in  Chief,  Central  Region  (NATO) 

CINCEUR  Commander  in  Chief,  U.  S.  European  Command 

CINCLANT  Commander  in  Chief,  Atlantic  Command 

CINCMAC  Commander  in  Chief,  Military  Airlift  Command 
CINCNORAD  Commander  in  Chief,  North  American  Air  Defense  Command 
CINCPAC  Commander  in  Chief,  Pacific  Command 

CINCRED  Commander  in  Chief,  U.  S.  Readiness  Command 
CINCSAC  Commander  in  Chief,  Strategic  Air  Command 
CINCSPACECOM 

Commander  in  Chief,  Aerospace  Command 
COMSPAWAR  Commander,  Space  and  Warfare  Systems  Command 
CRC  Control  and  Reporting  Center 

CRP  Control  and  Reporting  Post 

CWC  Composite  Warfare  Coordinator 

C2  Command  and  Control 

C3  Command,  Control  and  Communications 

C3CM  C3  countermeasures 

C3I  Command,  Control,  Communications  and  Intelligence 

DAISS  Digital  Airborne  Intercommunications  and  Switching 

System 

DASD  Deputy  Assistant  Secretary  of  Defense 

DFD  Data  flow  diagrams 

DIA  Defense  Intelligence  Agency 

DOD  Department  of  Defense 

DTWA  Dual  Trailing  Wire  Antenna 

EAM  Emergency  Action  Message 
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EAP 

EAUXCP 

ECM 

EIU 

EMI 

ESI 

ESM 

EW 

EWC 

FAAD 

FEMA 

F2D2 

GLISU 

GWEN 

HERT 

HF 

ICBM 

ID 

IFFN 

INTEL 

JCS 

JDL 

JTC3A 

JTF 

LD 

LF 

MCES 

MILSTAR 

MIT 

mod 

MOE 

MOFE 

MOP 

MORS 

MRT 

NADC 

NAF 

NAEW 

NATO 

NBG 

NCA 

NDS 

NMCS 

NORAD 

NOSC 

NPS 

NSA 

NSC 

NSWC 

OJCS 


Emergency  Action  Procedures 

East  Auxiliary  Airborne  Command  Post  (SAC) 

Electronic  Countermeasures 

Equipment  interface  unit 

Electro-magnetic  interference 

ESI  Systems,  Incorporated 

Electronic  switching  matrix 

Electronic  Warfare 

Electronic  Warfare  Coordinator 

Forward  Area  Air  Defense 

Federal  Emergency  Management  Agency 

Functional  flow  diagrams  and  description 

Ground  line  interface  and  signalling  unit 

Ground  Wave  Emergency  Network 

Headquarters  Emergency  Relocation  Team 

High  Frequency 

Intercontinental  Ballistic  Missile 
Identification 

Identification  Friend,  Foe,  or  Neutral 

Intelligence 

OJCS 

Joint  Directors  of  Laboratories 

Joint  Tactical  Command  Control  and  Communications 
Agency 

Joint  Task  Force 
Launch  Detection 
Low  Frequency 

Modular  Command  and  Control  Evaluation  Structure 
Military  Satellite  Communications 
Massachusetts  Institute  of  Technology 
Modification 

Measures  of  Effectiveness 

Measures  of  Force  Effectiveness 

Measures  of  Performance 

Military  Operations  Research  Society 

Miniature  Receive  Terminal 

Naval  Air  Development  Center 

Numbered  Air  Forces 

NATO  Airborne  Early  Warning  System 

North  Atlantic  Treaty  Organization 

Naval  Battle  Group 

National  Command  Authorities 

Nuclear  Detection  System 

National  Military  Command  System 

North  American  Aerospace  Defense  Command 

Naval  Ocean  System  Command 

Naval  Postgraduate  School 

National  Security  Agency 

National  Security  Council 

Naval  Surface  Weapons  Center 

Organization  of  the  Joint  Chiefs  of  Staff 
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ONR 

OSD 

OSN 

OTC 

PACCS 

PMR 

POC/ET 

QOT&E 

RO 

ROE 

RR 

SAC 

SACEUR 

SACR 

SAM 

SCO 

sees 

SDI 

SHORAD 

SIOP 

SIS 

SOC 

SPAWAR 

SSU 

TADIL 

TDS 

TFCC 

TWA 

VLF 

WWABNCP 

WAUXCP 

XTEL 


Office  of  Naval  Research 

Office  of  Secretary  of  Defense 

Office  of  the  Secretary  of  the  Navy 

Officer  in  Tactical  Command 

Post  Attack  Command  Control  System 

Program  management  reviews 

Proof  of  Concept,  Experimental  Testbed 

Qualified  Operational  Test  and  Evaluation 

Radio  operators 

Rules  of  engagement 

Radio  relay 

Strategic  Air  Command 

Supreme  Allied  Commander,  Europe  (NATO) 

Strategic  Air  Command  Regulations 

Surface  to  air  missiles 

Strategic  command  and  control 

Ship  Combat  Simulation  System 

Space  Defense  Initiative 

Short  Range  Air  Defense 

Single  Integrated  Operations  Plan 

Special  Information  System  (Intelligence) 

Sector  Operations  Center 

Statement  of  Operational  Capabilities 

Space  and  Naval  Warfare  Systems  Command 

Subscriber  station  unit 

Tactical  Data  Information  Link 

Tactical  data  systems 

Tactical  Flag  Command  Center 

Trailing  Wire  Antenna 

Very  Low  Frequency 

World  Wide  Airborne  Command  Post 

West  Auxiliary  Airborne  Command  Post  (SAC) 

Crosstell 
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